Radium 1.9.3 released

[kmatheussen]

I hope it is narrowing the problem a little bit.

Indeed.

I found the problem. A function that copies sound and applies volume only copied
sound if the volume was != 1.0. On intel, this seems to always be true.
But the function is supposed to copy sound even if the volume is 1.0.
(The reason for the bug was a missing else block, plus that the function should
check for 0.0 (which is explicitly set when muted), and not 1.0.)

Thanks for the help!

I don't know why the editor is messed up for you though,
but I've uploaded Radium v 1.9.11 now, which contains the volume fix.

Maybe this subtle difference between AMD and intel CPU can explain the
graphics bug as well. I'll look more into that, but can you also post a full
screenshot of the program? That would be extremely helpful.

Also, is the editor screwed up in any of the two other songs I linked to?
(which don't contain any tracks containing the sampler instrument)

[DoosC]

I found the problem. [...]
Thanks for the help!

Hurray ! That's great news !

but I've uploaded Radium v 1.9.11 now, which contains the volume fix.

Cool. Maybe Falktx will find some time to do an update in the repos.
But I tried the latest binary you sent and still no sound.

Maybe this subtle difference between AMD and intel CPU can explain the
graphics bug as well. I'll look more into that, but can you also post a full
screenshot of the program? That would be extremely helpful.

Sure !
radium (KXStudio) - Demo song:

Radium7.png (169.51 KiB) Viewed 299 times

radium_amd10.bin (latest) - Demo song:

Radium6.png (142.76 KiB) Viewed 299 times

Also, is the editor screwed up in any of the two other songs I linked to?
(which don't contain any tracks containing the sampler instrument)

It has glitches too. Less but still some :

Radium8.png (2.9 KiB) Viewed 299 times

[kmatheussen]

t has glitches too. Less but still some :

Radium8.png

Thanks for the pictures.

I'm pretty sure I've found the problem. If I add the following line to disk.c:
#define atof(a) 0

Then I get almost exactly the same artifacts as you.
I assume it's because disk.c doesn't include stdlib.h, which will explain the problem. What
I don't understand, though, is why only you see this problem. It's quite strange.
Maybe FalkTX knows? In which situations are stdlib.h not implicitly included? Are AMD and Intel
binaries built on different computers, for instance?
EDIT: No, this doesn't make sense. The same artifacts were on on the binary I created as well, and there were
no warnings during compilation of it.
EDIT 2: stdlib.h was included indirectly through another include file, so this was not the problem.

Anyway, I've uploaded a new version of http://users.notam02.no/~kjetism/radium_amd10.bin now.
EDIT: This version probably won't work, but it might pop up a window during loading to inform
what went wrong. If so, it would be very useful to know what it says.

[DoosC]

Weirder and weirder, same part of the screen, both with demo song :

1.9.11 from KXStudio, now visually funny too... and still no sound and no sound meters moving.

Radium9.png (42.36 KiB) Viewed 294 times

latest radium_amd10.bin, visually funny but slightly different. Still no sound and sound meters not moving anymore + a weird message on start

Radium10.png (14.34 KiB) Viewed 294 times

Radium11.png (38.3 KiB) Viewed 294 times

Maybe it would help to have someone else report its experience with an AMD processor. Anyone here ?

[kmatheussen]

[attachment=1]Radium10.png

Thank you. That's the error I expected, actually:

both atof("0.500000") and strtod("0.500000",NULL) returns 0.0!

Why? Anyone knows? I've googled it, but can not find any reason why this should happen.
errno was not set by strtod.

[kmatheussen]

[attachment=1]Radium10.png

Thank you. That's the error I expected, actually:

both atof("0.500000") and strtod("0.500000",NULL) returns 0.0!

Why? Anyone knows? I've googled it, but can not find any reason why this should happen.
errno was not set by strtod.

Googling some more. Seems to be caused by locale settings. I guess you have an LC_* environment
variable set to a language that uses "," instead of "." for floating points. (perhaps you should change that)

I've uploaded 1.9.12 with this fixed (plus various other things), and I've also uploaded a new version of
http://users.notam02.no/~kjetism/radium_amd10.bin again. Now it should work.

[kmatheussen]

Updated the KXStudio package to 1.9.12.
I hope this is fixed now.

Thanks for the help falkTX!

[kmatheussen]

Updated the KXStudio package to 1.9.12.
I hope this is fixed now.

I just tried your package on a different computer.
The package is missing the file /usr/lib/radium/packages/xmessage-1.0.3/xmessage
Missing the xmessage binary causes warning and error messages not to be shown.
It would be great if you could fix this. It's important when debugging
when someone has problems.

[DoosC]

Googling some more. Seems to be caused by locale settings. I guess you have an LC_* environment
variable set to a language that uses "," instead of "." for floating points. (perhaps you should change that)

uh... yeah that's because my system is set to french but I don't intend to change that.

I've uploaded 1.9.12 with this fixed (plus various other things), and I've also uploaded a new version of
http://users.notam02.no/~kjetism/radium_amd10.bin again. Now it should work.

Well, this time it is really broken : http://pastebin.com/ufae56SN

[kmatheussen]

Googling some more. Seems to be caused by locale settings. I guess you have an LC_* environment
variable set to a language that uses "," instead of "." for floating points. (perhaps you should change that)

uh... yeah that's because my system is set to french but I don't intend to change that.

I've uploaded 1.9.12 with this fixed (plus various other things), and I've also uploaded a new version of
http://users.notam02.no/~kjetism/radium_amd10.bin again. Now it should work.

Well, this time it is really broken : http://pastebin.com/ufae56SN

I've seen something like that too sometimes, although not with so extreme usage of memory that it actually runs out of memory.
I think it's related to something with jack. Maybe jack is in a bad shape when you ran the program. Try restarting jack.
It could also be a bad match of the binary file itself and the other files belonging to radium,
so maybe the 1.9.12 version in kxstudio works better.

[DoosC]

Hurray !!!

Sound !

Finally the latest KXStudio version made it. The window is much less broken also. Seems to be in a good shape for now on

Radium12.png (106.11 KiB) Viewed 304 times

Ok now the hardest part for me: find the (rare) time to properly test radium and see what's in its guts

[kmatheussen]

Hurray !!!

Sound !

Finally the latest KXStudio version made it. The window is much less broken also. Seems to be in a good shape for now on

Radium12.png

Ok now the hardest part for me: find the (rare) time to properly test radium and see what's in its guts

Good to hear.

I'm looking in to the memory bug now, but it's a hard since I don't know how to provoke it.

Also, you should perhaps go into the edit menu and select "Set Default Editor Font" and "Set Default System Font"
since the fonts in the picture looks completely wrong. After selecting those, the fonts should like in the picture below.
If not, there's something wrong.

[kmatheussen]

Updated the KXStudio package to 1.9.12.
I hope this is fixed now.

I just tried your package on a different computer.
The package is missing the file /usr/lib/radium/packages/xmessage-1.0.3/xmessage
Missing the xmessage binary causes warning and error messages not to be shown.
It would be great if you could fix this. It's important when debugging
when someone has problems.

hm, I think we already gone through this.
There is no point on supplying an extra binary of xmessage when the system already has that. I see no point on doing this... (unless yours is custom patched?).

Can you make it possible to use system xmessage if that filepath is not found? thanks!

(btw, I'm still on the opinion that you should NOT use xmessage at all. Please use real dialogs, like these: http://doc.qt.digia.com/qt/qinputdialog.html#details)

I understand, but it's about what to prioritize spending time on. Using qt dialog instead of xmessage is definitely important in order
to better debug radium on windows and osx, but there are currently many other things which are more important right now. I don't
understand why you need to actively remove xmessage after installing radium. What kind of harm does it do? I don't to use a system xmessage, because
I want to be sure that it works the way radium uses it (parameters). In addition, (at least) earlier versions of fedora wrongly had gtk1 as a dependency for xmessage.

[kmatheussen]

I understand, but it's about what to prioritize spending time on. Using qt dialog instead of xmessage is definitely important in order
to better debug radium on windows and osx, but there are currently many other things which are more important right now. I don't
understand why you need to actively remove xmessage after installing radium. What kind of harm does it do? I don't to use a system xmessage, because
I want to be sure that it works the way radium uses it (parameters). In addition, (at least) earlier versions of fedora wrongly had gtk1 as a dependency for xmessage.

This is about confirming to the debian policy. Wherever an app has built-in libraries/code that is already in the distro, use the distro version if possible.
I would compile radium with system libgc, libgig and fluidsynth, but your Makefile doesn't make that very easy, so I skip this for now. If you ever want to see Radium in Debian one day, you should really consider getting rid of internal packages/ and use system ones (giving a build error when a specific lib is not found).

anyway, I'll update the package to use your xmessage version, but really, please, consider not doing that...

Thank you. libgc, libgig and fluidsynth are all modified by me, so please don't replace them. Plain libgc aborts in windows when printing warnings, plain libgig prints out a million messages to stdout and refuses to parse some soundfonts, and plain libfluidsynth uses much more memory. It's also much better to provide as many packages as possible, to make sure packages fit together and are tested properly. The debian policy is wrong.

[kmatheussen]

libgc, libgig and fluidsynth are all modified by me, so please don't replace them. Plain libgc aborts in windows when printing warnings, plain libgig prints out a million messages to stdout and refuses to parse some soundfonts, and plain libfluidsynth uses much more memory.

I know you had a custom libgc, but didn't know about libgig and fluidsynth mods. Can you share those patches?

It's also much better to provide as many packages as possible, to make sure packages fit together and are tested properly.

I don't agree with this, but it's just my opinion.
As I see it, you're kinda forking those projects and (probably) not reporting back upstream the changes you made. The problem is when upstream releases a new version with X new feature - if we want that in radium only you could made that happen. If radium used system libs then any new libgig or fluidsynth features would be available right away.

Of course it's reported upstream, except for the libgig changes which are only relevant for radium.
It could also take years before upstream changes are put into the distributions. Debian "stable" once had a buggy version of jack
for a very long time, maybe years. It was frustrating both for the jack developers and us who developed jack programs.
EDIT: That package is in fact still in debian "oldstable".