Now uses separate paths for each ASL requester, so it should be more convenient if you have modules in one dir and samples somewhere else
Oh cool, thanks - a small addition for the programmer but a giant leap for the composer! And as I was the one requesting this feature, I'll send a small donation your way.
Two more little things come to mind with regard to the next release candidate:
- Could you please add a version string? - Because the Amiga port handles file paths in its own way (through ASL), perhaps you could also add icon tooltypes for the default module and sample paths for the ASL requester to pick up?
- Because the Amiga port handles file paths in its own way (through ASL), perhaps you could also add icon tooltypes for the default module and sample paths for the ASL requester to pick up?
Currently requester code is not aware of sample/module/other at all, it simply stores paths like:
dict["dialog title"] = path
So there would have to be some kind of mapping from tooltype to dialog title for this mechanism to work.
MilkyTracker has a config file so ideally upstream could implement some path storage (maybe there is, didn't check it yet).
Link to the new SDL 2.0.14 version: this should fix some cosmetic issues in fullscreen related to ASL requester. Add version string. Add stack cookie of 100000 bytes.
I just downloaded, and I must have something set wrong because playback is very choppy and sounds bad. Playback with a much older version of Milky is fine. This is on my X1000 using motherboard audio. Something I missed?
Thanks for response. The older version I have installed on my X1000 since ages is 0.90.80. It plays back fine. I don't ever create anything with it, just play modules made by others. Only thing I don't like about this version is I cannot figure out how to tell its built-in file requester to go to another device/volume -- only to folders going back to root. Probably I am missing something obvious.
Was pleased to see your version uses ASL, and that works a treat. Just have this problem where playback is bad. In fits and starts, very choppy. Maybe there is a setting I can adjust if this is not a bug???
Again, I am using an X1000 with Lyle's audio driver for onboard sound, and I am running OS4.1 FE Update 2.
Could you check the CPU usage without MilkyTracker and with MilkyTracker? Could you also check if there is some debug "storm" on the serial port, for example using Sashimi tool?
Have you tried removing the MilkyTracker config file?
It would be great is someone else with X1000 could also test?
EDIT: Actually the testing took me minutes not hours, and all is good here.
When I went to test against I found that I had too hastily deleted the new MilkyTracker so after I extracted the program from the archive again and ran it and used it to play some modules.... well, I find that all is working fine. Playback is perfect.
So I do not know what the problem was previously. My apologies for sounding the alarm. All is well here.
Edited by mbrantley on 2021/4/3 19:32:10 Edited by mbrantley on 2021/4/3 19:32:41 Edited by mbrantley on 2021/4/4 12:03:17
I noticed someone is reporting a black screen issue on OS4Depot.
Which system (hardware)? For example under WinUAE you need to use PatchCompositeTags or switch to "software" renderer. As normally SDL2 apps use the "compositing" renderer.
Capehill wrote:If you are using "overscan" as logical size mode, then it could have problems. In such a scenario please switch to default/letterbox mode.
Overscan (with compositing driver) should work now, too.
Tested under AmigaOs4.1 Qemu Pegasos 2. SDL Prefs are on default settings. With software and compositing it was tested also here black screen. The sdl1.x version of MilkyTracker works.
Ok sorry I reported this error on Os4depot it works perfectly with Warzp3D under AmigaOs4.1 Pegasos 2 Qemu. I measured to set the settings to Opengl in prefs SDL2.But software rendering and compositing do not work, which it should. Compositing is supported by the sm501 driver under AmigaOs4.1/Qemu Pegasos 2.
It is the same problem as with ScummVM there you also get only a black window. Your new version looks a bit more distorted than the os4depot version with older SDL2. Please compare the pictures.
Edited by Maijestro on 2023/4/29 13:21:22 Edited by Maijestro on 2023/4/29 13:22:30 Edited by Maijestro on 2023/4/29 13:23:25 Edited by Maijestro on 2023/4/29 14:07:50
It seems that even if you ask for software renderer, SDL tries to accelerate the framebuffer and create compositing renderer behind the curtains. You could try to disable it by "setenv SDL_FRAMEBUFFER_ACCELERATION 0" and see what happens with "software" driver.
I got mixed results on WinUAE. "software" works OK on a 32-bit screen but for some reason driver is swapped from "software" to "compositing" on a 16-bit screen. No idea why, need to debug more.
OpenGL mode I didn't try but I saw something similar using PatchCompositeTags. Actually whole window content breaks on resize which doesn't happen on native system. When you resize a Wazp3D window, does it break completely?
It seems that even if you ask for software renderer, SDL tries to accelerate the framebuffer and create compositing renderer behind the curtains. You could try to disable it by "setenv SDL_FRAMEBUFFER_ACCELERATION 0" and see what happens with "software" driver.
This line does not bring any improvement, the window opens and flickers 2-3 times and then I have the black content again.
Quote:
I got mixed results on WinUAE. "software" works OK on a 32-bit screen but for some reason driver is swapped from "software" to "compositing" on a 16-bit screen. No idea why, need to debug more.
I think it's a bug in the SDL2 release under AmigaOs4.1, I would make myself available as a beta tester to fix SDL2, especially the software/compositing part seems to be broken.
Quote:
OpenGL mode I didn't try but I saw something similar using PatchCompositeTags. Actually whole window content breaks on resize which doesn't happen on native system. When you resize a Wazp3D window, does it break completely?
The whole thing runs very stable via Wazp3D the window can be enlarged as desired and the tracker scales with it. I have recorded a small video so you can see it better.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
