As a Christmas present to all AmigaOS4 users, I have just released a new OS4 port of Protrekkr, a powerful multi-platform music tracker written by Franck 'hitchhikr' Charlet. With its superb features that include realtime software synthesis, Roland TB-303 emulation and numerous effects, Protrekkr is by far the most capable tracker ever available on an Amiga platform. The release comes with almost 50 example songs (modules) to show what the program can do.
This new AmigaOS4 port is special in that it allows further configuration via tooltypes in the program icon. These additional settings allow tweaking the GUI to make Protrekkr more usable in large screen resolutions.
NOTE: The tracker can get quite CPU-intensive: a 1.5 GHz processor may be the bare minimum when replaying complex modules (16 tracks with all effects/polyphony on). The AmigaOS4 version has been tested and performs well on an AmigaOne X5000/020. Performance on slower systems may be less plausible.
Thanks for the port Protrekkr, it seems to be a powerful tracker with lots of features.
I don't want to criticize your work, but in my opinion this port is incomplete and not optimized. When loading the example songs I get 100% CPU load, some songs can play, others play garbled.
If you run Protrekkr without playing the sample songs, Protrekkr will require about 27 CPU load. If I load a song without playing it, the CPU load increases to incredible levels.
Please don't misunderstand me and I don't want to badmouth your work for God's sake, but as you mentioned this port should only be used on x5000/20/40.
Edit: Playing mod files works perfectly with 50% cpu load. So we could be right that 16 voices are simply too much for slower machines.
It's a great tracker, I didn't know it existed until today
Edited by Maijestro on 2023/12/26 9:55:13 Edited by Maijestro on 2023/12/26 10:01:43
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
Yes, the program is a hog, but that's simply because multi-track mixing, realtime synthesis and effects take a lot of CPU power. In the author's original docs, even PC users are warned that a fast machine is needed. So I don't expect that the experience will be great on Sam systems.
The AmigaOS4 version is a straight SDL port (with a few Amiga-specific additions), and given that the source code is big and not exactly well written, I have no idea how to optimize it. Perhaps adapting it to use SDL2 instead of SDL1 could help in some ways, but I don't have the time or skills to do that.
If you run Protrekkr without playing the sample songs, Protrekkr will require about 27 CPU load.
One thing that makes SDL ports inherently sluggish on lower-end machines is the event loop. SDL-based programs typically use a busy loop, which is very ineffective and causes a lot of overhead. I don't think it can easily be replaced with a traditional Wait()-loop to make a more optimized Amiga port.
One thing that makes SDL ports inherently sluggish on lower-end machines is the event loop. SDL-based programs typically use a busy loop, which is very ineffective and causes a lot of overhead. I don't think it can easily be replaced with a traditional Wait()-loop to make a more optimized Amiga port.
Unfortunately, I have no idea about these things, so don't be confused. Maybe it's just the "ptk" format that causes a lot of CPU overhead when loading.
As I mentioned earlier, this tracker plays mod files very well and even better than the PT2 clone. I won't be able to play more than a few mod files with this tracker, but I really like it and it has a permanent place on my MusiK partition
Thanks again for the port.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
Have you tried to play with PROTREKKR_MAIN_LOOP_DELAY env variable discussed on os4depot comments section? IIRC it did have some positive effect on playback with slower machines.
It took some time to test this release since my soundcard was fried during a short break.. luckily got a spare SB live 5.1 card gathering dust on my peg2.
On quick test everything seems to be working fine as usual. New Amiga specific options are definitely needed, I can finally see something
Btw, os4depot release has icon tooltype for "linespacing" while readme mentions "rowspacing" (and this tooltype also does something).
Anyways, thanks again for the update - I'll keep on testing this. So, is the next milestone MIDI?
Have you tried to play with PROTREKKR_MAIN_LOOP_DELAY env variable
This variable will be ignored as from the upcoming Release 2, which is due soon. A new tooltype setting, MAINLOOPDELAY, has been introduced to make the OS4-specific settings consisent.
The main loop delay is a setting that simply makes the program's main input loop wait for a specific time at the end of each cycle. By default, the value is 10 milliseconds on most platforms. The OS4 and AROS versions have 40 ms as default (not my decision), to make the program less of a strain on the system. However, the higher the value, the less responsive the program becomes (especially the GUI updating will start lagging behind), so you need to find a compromise value that fits your system. I use 20 ms on my X5000/020 and the setting seems fine.
Quote:
New Amiga specific options are definitely needed, I can finally see something
The necessity to do something about the program's screen size was the main reason why I took up the port! I had played with the previous OS4 port several times, but I always gave up because of too much eye strain. The Protrekkr GUI is not scalable and having been written many years ago, it doesn't lend itself very well to modern screen resolutions. I find that 800x600 or 1024x768 are the best settings on my 32" monitor.
Quote:
os4depot release has icon tooltype for "linespacing" while readme mentions "rowspacing"
Sorry, this is my mistake I made as I was trying to get the program out of the door on Christmas Day The correct name of the tooltype is ROWSPACING (because tracker patterns have rows, not lines). As of Release 2, ROWSPACING will accept a value between 8 and 12, to improve the readability of the pattern.
Quote:
So, is the next milestone MIDI?
Much as I would like to see MIDI supported (and continue the effort that Tomppeli started years ago), I'm not sure I'm up to it - I'll have yet to see if the RtMidi class can reasonably be translated to camd.library functions. But I want to give it a try at some point, just to see if I can kill off OctaMED completely
Currently, the next milestone is improved documentation; Protrekkr is very complex and tutorials are needed so that people can start using the program.
Currently, the next milestone is improved documentation; Protrekkr is very complex and tutorials are needed so that people can start using the program.
Will those tutorials be aimed at novice users or more focused to experimented user/musicians/composers?
I would like to learn how to use trackers but sadly I have zero music background, so tutorials in how to get starting with tracker, even for someone like me would be nice.
Nice program. Thanks for the port. I can confirm that the gui is the cpu hog. Everything runs fine unless I enlarge the window to show show all 16 tracks. Then even the X5000 will reach 100% cpu load. So maybe we should try to get rid of SDL and make the gui os4 native.
So maybe we should try to get rid of SDL and make the gui os4 native.
Rewriting the program for SDL2 might be an easier solution, as SDL2 can use hardware-accelerated renderers.
That being said: I don't see myself up for a task other than tweaking the program to be more configurable and Amiga-friendly. Protrekkr is not very well written: it uses an insane amount of global variables (making the program prone to side effects), it mixes C with C++, and the source code is sparsely documented. It would be a hell of a job.
I remember trying to make fonts more readable by creating custom fonts. Fonts are editable bitmaps and their width can be defined in fontdatas.txt. I don't know if height can be controlled somehow outside of source code.. It would help a lot if spacing around fonts (and font size itself) could be changed. Dunno how this is done in code and how PT's gui does the scaling.
Native gui would be neat, SDL2 version with accelerated renderer as well.
Quote:
Much as I would like to see MIDI supported (and continue the effort that Tomppeli started years ago), I'm not sure I'm up to it - I'll have yet to see if the RtMidi class can reasonably be translated to camd.library functions. But I want to give it a try at some point, just to see if I can kill off OctaMED completely
Would be awesome :) Let me know if you need any help!
Protrekkr only scales the pattern editor and the listbox in the top-right section of the display. The position and size of all other GUI elements are hardcoded in the GUI. And I really mean hardcoded - it doesn't even use size constants that you could easily change in one place!
I have just spent two days trying to tweak the GUI, and I have at least succeeded in making the smallest buttons (SEL. TRACK, CUT, PASTE etc.) a little bigger. I'll continue exploring the possibilities, but I don't think I'll have time to make the GUI fully scalable. The program is perfectly usable when run on a 1024x768 screen, which is what matters to me at the moment.
Quote:
Native gui would be neat
I won't take the plunge and change SDL to Intuition, but I'll at least try to implement native Amiga menus.
Wow... this Tracker is actually quite darn awesome! Been playing through the example songs and yeah... The synths/303s and other effects really makes it sound very organic and not the usual "tracker feel" to the music.
Tutorials / documentation on how to use it would be awesome!