Arkos Tracker 2 - Released!

[reidrac]

But thinking about it, maybe you could use another assembler (Rasm, SJasmplus) only for the player (using a fixed address), then integrate the generated binary using SDCC ?

Yes, I thought about that, but the point of using the SDCC assembler is that the linker will relocate the code around as needed, so it allows me to use all the memory without thinking about it.

I've converted 90% already; although I haven't tested that I didn't break anything (that's going to be fun!). I can contribute the source if you think that would be useful (thinking about it, is CPCTelera using Arkos 1 and SDCC?).

Thank you for the tracker (and the player). Having the tracker working natively in Linux is just amazing!


PS: please tag me in your replies so I get a notification! Thanks!

[Targhan]

@reidrac
Thanks for your remarks and support. You didn't answer the question : does this weird UI bug happens on load song, but also on "save as", and "load/save" insrument too ?

Yes, I thought about that, but the point of using the SDCC assembler is that the linker will relocate the code around as needed, so it allows me to use all the memory without thinking about it.
I've converted 90% already; although I haven't tested that I didn't break anything (that's going to be fun!). I can contribute the source if you think that would be useful (thinking about it, is CPCTelera using Arkos 1 and SDCC?).

CPCtelera supports Arkos Tracker 1, I don't know what compiler it uses though.
Contribution could be useful, but I'm not sure this is such a great idea, because I would have to support it! The player has already changed a bit in the next version, I don't want to also have to change the SDCC code too, because it's a lot of work. I have automatized test units for all my players, but this is not easy to set up (I embed Rasm in my C++ code). I'm not planning on also embedding SDCC... I hope you understand!


But you can make me change my mind .

[reidrac]

@reidrac
Thanks for your remarks and support. You didn't answer the question : does this weird UI bug happens on load song, but also on "save as", and "load/save" insrument too ?

It looks like it happens in all file dialogs, so yes... "save as" and load/save instruments look the same. What is the toolkit that you're using? Where is it getting the theme from?

There are other bits I can't read. I would prefer a more "plain" look TBH.

CPCtelera supports Arkos Tracker 1, I don't know what compiler it uses though.
Contribution could be useful, but I'm not sure this is such a great idea, but I would have to support it! The player has already changed a bit in the next version, I don't want to also have to change the SDCC code too, because it's a lot of work. I have automatized test units for all my players, but this is not easy to set up (I embed Rasm in my C++ code). I'm not planning on also embedded SDCC... I hope you understand!


But you can make me change my mind .

It's probably easy for me to port those small changes and as long as the code is fine, I don't mind "freezing" to that tracker/player code. I mean, I won't update the games once released anyway

[cpcitor]

May be is some sort of weird behavior with XFCE. My theme is not special I think (and my apps don't look like Arkos Tracker 2!).

I'll double check, but if it works fine for everybody else, forget about it.

Same here. I'm using XFCE with a pretty ordinary light theme (MurrinaElement) and observe exactly the same contrast problem.

It looks like it happens in all file dialogs, so yes... "save as" and load/save instruments look the same. What is the toolkit that you're using? Where is it getting the theme from?

Arkos uses JUCE, a music-oriented application-developing framework.

There are other bits I can't read. I would prefer a more "plain" look TBH.

Same for me. I prefer when program don't try to change color at all.

I've been also on the other side (app developer) and can witness that color conflicts in UI easily happen.

There are solutions guaranteed to work, if the toolkit used lets developer enough freedom:

• either don't change any color, not even one. This also implies developer must ensure any graphics are either in their own non-transparent rectangle with some margin, or with free shapes with an outline that guarantees luminance contrast whatever the surrounding theme-dependent color. This is what most open-source software does, lets total freedom (and responsibility) to the user, and is out-of-the-box compatible with dark themes, light themes, etc.
  
• or specify every color everywhere and make sure not a single color "leaks"/inherits from environment/theme/user customization. This way developer has total control and is totally responsible for user comfort (or lack thereof).
  

In my experience, any deviation results in users reporting problems, and strictly following one of these ways solves them.

Arkos, does Juce gives developer enough freedom to implement one, the other, both?

[Targhan]

I do not use any custom/JUCE File Picker (I explicitly indicate to use the native file picker), and that's the behavior I have always seen on Windows, Linux and Mac. So what you report is striking to me.
Since I never asked to use a Juce FilePicker (yet it uses one, for whatever reason), the color scheme is broken because I never implemented it.


Juce doesn't impose anything, I can create my own FilePicker, but I won't. I'll ask the devs if they have a solution.

[cpcitor]

I do not use any custom/JUCE File Picker (I explicitly indicate to use the native file picker), and that's the behavior I have always seen on Windows, Linux and Mac. So what you report is striking to me.
Since I never asked to use a Juce FilePicker (yet it uses one, for whatever reason), the color scheme is broken because I never implemented it.


Juce doesn't impose anything, I can create my own FilePicker, but I won't. I'll ask the devs if they have a solution.

Wondering to what extent this is a reply to my post. In a properly designed, framework, this has nothing to do specifically with a file picker, but it has to do with theming.

• Does your code anywhere manually overrides some colours? Then consider overriding all theme colours. Perhaps offer a user-settable options that allow to disable all colour overriding, just let default theme.
• Have you selected a non-default theme? If yes, then it probably does not set all colours. Consider reporting to theme author or trying another theme. Same suggestion as above, too.
  
• Have you not set anything related to colours? In that case, the issue is in Juce itself. Reporting to Juce author may be your best bet.

I'm pretty confident a simple solution exists.

[Targhan]

This was an answer to your post. With Juce, you can either use the native OS File picker, or use the JUCE one. The JUCE one can be customized. Since I did NOT want to use the JUCE one, I simply overrode the colors I needed (generic text color, background color, etc.). I guess there are some "file picker background" that CAN be overridden, but I never had to check for this.


Once again : the UI for the FilePicker you are seeing is NOT meant to be seen, in fact I never saw it myself! This is a JUCE specific bug with your Linux theming.

[reidrac]

This was an answer to your post. With Juce, you can either use the native OS File picker, or use the JUCE one. The JUCE one can be customized. Since I did NOT want to use the JUCE one, I simply overrode the colors I needed (generic text color, background color, etc.). I guess there are some "file picker background" that CAN be overridden, but I never had to check for this.


Once again : the UI for the FilePicker you are seeing is NOT meant to be seen, in fact I never saw it myself! This is a JUCE specific bug with your Linux theming.

Wild guess... It may be related to GTK2 or GTK3 themes.

I can help with testing, I'll try to research a workaround in case it is related to that. Currently, is usable by typing in the location input because I can't read it

Anyway, thanks for looking at this and for supporting Linux!

[cpcitor]

I do not use any custom/JUCE File Picker (I explicitly indicate to use the native file picker), and that's the behavior I have always seen on Windows, Linux and Mac. So what you report is striking to me.
Since I never asked to use a Juce FilePicker (yet it uses one, for whatever reason), the color scheme is broken because I never implemented it.

Juce doesn't impose anything, I can create my own FilePicker, but I won't. I'll ask the devs if they have a solution.

Thank you for this explanation. Since the tracker is not open-source, we cannot test variants by ourselves. Can you share a minimal test project source code? Just a window, a button that opens the filepicker and that's it. Then we can easily test, report, test variants and offer something that works for us. It's probably the quickest way to find a solution that works well for everyone. What do you think?

[Targhan]

Don't worry, I'll use a VM and check for myself. I'll also ask the JUCE devs.

[Targhan]

Actually, sending you a small EXE is a good idea. I'll try to do something by the end of the week, I'll PM you both. Thanks!

[reidrac]

Actually, sending you a small EXE is a good idea. I'll try to do something by the end of the week, I'll PM you both. Thanks!

Thanks!

I've been fiddling with the themes in my XFCE, both with GTK2 and GTK3, with no change.

[Targhan]

@reidrac
@cpcitor
Please find attached an executable of a simple program which, when the button is clicked, opens the file picker. Can you test it and confirm me that you can see the NON-native file picker with Linux and your XFCE? Thanks!

[cpcitor]

Please find attached an executable of a simple program which, when the button is clicked, opens the file picker. Can you test it and confirm me that you can see the NON-native file picker with Linux and your XFCE? Thanks!

I see a file picker that does not look like usual file pickers, so I guess it is non-native.
Colors are readable.
See attached image.

filepicker_.png
(37.57 kB, 600x500 - viewed 136 times)

[reidrac]

I see a file picker that does not look like usual file pickers, so I guess it is non-native.
Colors are readable.
See attached image.

filepicker_.png
(37.57 kB, 600x500 - viewed 136 times)

Yes, same here... but, hey! I CAN READ THAT! So for me, is success!

[Targhan]

Thanks a lot. The fact that it is readable is only because it uses the native JUCE colors. I'll file a bug, since the native OS File Picker should be seen.
If they don't want to correct this, I am still able to override the right colors to make it readable, so it will eventually look right .

[mahlemiut]

At least you all are getting file pickers... 

[Targhan]

It seems JUCE is looking for the FilePicker exe called "kdialog" and "zenity". It probably doesn't find them, and uses its own FIlePicker as a fallback. Does it make sense to any of you?

[reidrac]

It seems JUCE is looking for the FilePicker exe called "kdialog" and "zenity". It probably doesn't find them, and uses its own FIlePicker as a fallback. Does it make sense to any of you?

Yes, it does. kdialog is part of KDE (not XFCE); Zenity is a Gnome app to show dialogs. I'm surprised JUCE is using those. For example, Zenity description is "Display graphical dialog boxes from shell scripts", so it is a weird thing to use from a native GUI app I think.

Anyway, I installed Zenity and now the dialogs are OK (is not XFCE, but the theme is OK).

Perhaps it would be useful to mention that in the docs or something like that (that you need either kdialog or zenity installed).

[reidrac]

@Targhan another issue (sorry), not sure if is known or not.

I'm trying to export a STarKos song into an AKL bin and I only get a crash (exported file 0 bytes).

Exporting to source works fine though.

You can reproduce it with Dea on Time in game music song.

Other times gets stuck using CPU and nothing happens, until it crashes.

[Targhan]

Ok thanks for all this information. For the crash, I'm looking into it. As for the File Picker, I'll improve the color scheme so that the JUCE file picker shows right, and I'll post on the website the information you provided. Thanks!

[Targhan]

@reidrac Mmmh, I can not reproduce on Windows and Linux, on the released alpha version. I tested for Dead On Time Ingame and Main menu songs, exported to Binary, Lightweight format. Is it what you tried to do?

Does it happen for any other STarKos song or only these ones?

[reidrac]

@reidrac Mmmh, I can not reproduce on Windows and Linux, on the released alpha version. I tested for Dead On Time Ingame and Main menu songs, exported to Binary, Lightweight format. Is it what you tried to do?

Does it happen for any other STarKos song or only these ones?

Yes, it happens when exporting binary in lightweight format; with any song.

The problem is related to the source profile; using Z80 with comments works. My profile only changes the byte and word declaration, but for some reason, that profile crashes all the time.

[reidrac]

@Targhan Quick question! (sorry to be a pain)

How can I stop the music? I tried to stop calling PLY_LW_Play from my int handler, but that leaves the PSG in a state that may left noise behind. I haven't found this functionality in the code.

Basically, how do I mute all channels?

[mahlemiut]

It seems JUCE is looking for the FilePicker exe called "kdialog" and "zenity". It probably doesn't find them, and uses its own FIlePicker as a fallback. Does it make sense to any of you?

Aha, I didn't have kdialog installed, it isn't required for Plasma (it allows file dialogs to be accessed via a shell script).
Installing kdialog fixes the problem.
Now all it needs is a volume control for audio output, it's a bit loud relative to pretty much any other application.