Musagi for Linux (chiptunes music composition)

stqn · 2010-08-11 10:49:55

In case someone is interested, I have made a port of Musagi for Linux. This is a music composition software that was originaly made by DrPetter for the Windows platform. It is targeted at chip-tunes creation, and is quite easy to use. There is a nice tutorial at http://www.drpetter.se/tutorial_musagi1.html

32 bit executable and source code are available on BitBucket: https://bitbucket.org/stqn/musagi-stqn/downloads

For now, this is a debug build, in case things go wrong on some peoples' machines. The OpenGL display is quite heavy on the CPU (under Windows too) and I'd like to fix this some time in the future. Some other things are probably not perfect either; you're welcome to report them if they are a problem for you. I might get the motivation to fix them.

Libs used: SDL, GTK, OpenGL, PortAudio (v18).

Edit: Something I should mention is that PortAudio v18 supports OSS only, so you need to stop all sound-using apps before launching Musagi. This is another thing I'd like to fix.

Edit 2: Now uses PortAudio v19 and ALSA; no need to stop other apps.

Last edited by stqn (2011-02-26 18:42:41)

SanskritFritz · 2010-08-11 11:04:33

This is very good news, I'll give it a try as time permits.
Thank you for your contribution!

Inxsible · 2010-08-11 12:03:51

I think this will be better served in the Community Contributions as this is not a request for help/support

linkmaster03 · 2010-08-11 18:05:02

Wow, this looks very cool. I will try it soon! Will it work with the version of portaudio in the community repository? (v19)

stqn · 2010-08-11 22:12:17

Inxsible, thanks for moving the thread in the correct forum.

linkmaster03, no I don't think it will, because I have read that v18 and v19 have a different API. I have included libportaudio.so in the pre-built archive though.

If your system's libportaudio.so (v19) is loaded instead of musagi's directory's libportaudio.so (v18), then I think this could be solved with LD_PRELOAD... Something like:

LD_PRELOAD=./libportaudio.so ./musagi

teh · 2010-08-11 22:34:23

This made my day. Amazing contribution!

stqn · 2010-08-11 23:20:53

Please tell me if it works fine! (I'm a bit anxious, eh eh...) Here the buttons are not always very responsive (if I click too fast they don't work). Also as I said the rendering is slow and thus jerky. But I have relatively old hardware. There is also a bunch of stuff that I haven't tested.

spctrl · 2010-09-28 22:34:26

Fails to compile here:

In file included from main.cpp:104:0:
gin_operator.h: In member function 'virtual bool gin_operator::Load(FILE*)':
gin_operator.h:634:48: error: cast from 'GearStack*' to 'int' loses precision
gin_operator.h:635:48: error: cast from 'GearStack*' to 'int' loses precision

stqn · 2010-09-28 23:03:17

Unfortunately I don't have a 64bit processor, so 64bit compilation hasn't been done.

As far as I understand the code, the loss of precision shouldn't be a problem because the value being cast to int should always be between 0 and 127 (it's not actually a pointer when read from disk, but an index.) Sooo... To remove the error, try this:

params.gearstack1=MapToGearStack((int)((uintptr_t)params.gearstack1&0xffffffff));
params.gearstack2=MapToGearStack((int)((uintptr_t)params.gearstack2&0xffffffff));

spctrl · 2010-09-29 00:17:23

ok, it compiles now (after a bunch of portaudio V19 changes i had to make), but it refuses to load any of the provided sample songs. Saying "Unknown song format (maybe incompatible version)"

Edit:
haven't looked into this too much, but kfread2 seems a little odd. Or at least the LoadSong() in main_fileops.h.
first it calls kfloadknobs (that reads 1 int, 1024 unsigned longs, 1024 float*s from the START of the file). then it reads 5 bytes from the START of the file. shouldn't this process keep track of how much it has read between calls to kfread2 and read from that position? As I said, I haven't looked into this too much, and I certainly haven't looked at the format itself. Also I think you are using fread in kind of the reverse. you have fread(*ptr, num, size, *FILE) but the definition is fread(*ptr, size, num, *FILE).

on the other hand I might be completely wrong, because from your hg commits it seems you have actually managed to load the songs. no idea..

Last edited by spctrl (2010-09-29 01:13:32)

spctrl · 2010-09-29 01:22:28

Upon more investigation it seems that the C Run Time implementation of fread by Microsoft behaves differently. you will have to change all this to get this working properly. fread in linux does not (from what I can understand anyway) increment the filepointer. so that's why you are just reading from the beginning of the file over and over again..

stqn · 2010-09-29 01:28:29

It's definitely working in 32bit. Could you post your patch or current source code somewhere so I can have a look at it?

Someone on the musagi forum apparently had the same problem after converting the source to 64 bit and portaudio v19, but I have yet to hear back from him... So your source would be helpful .

Edit: Oh, right. The problem is most probably here:

void kfloadknobs(FILE *file)
{
    LogPrint("kfsaveknobs: loading header");
    kfread2(&kf_numknobs, 1, sizeof(int), file);
    kfread2(kf_fknobs, 1024, sizeof(DWORD), file);
    kfread2(kf_pknobs1, 1024, sizeof(float*), file);
}

sizeof(float*) is 8 on 64bit, and 4 on 32bit. The songs were saved in 32bit mode, so they can't be loaded in 64bit. Since it's unlikely that pointers are stored in the files, this probably can be changed to sizeof(int) or something like that...

Last edited by stqn (2010-09-29 01:49:09)

spctrl · 2010-09-29 02:09:59

yeah sorry, disregard my rambling about fopen and not incrementing the file pointer, it does that. But it's weird that i see no mention of it in the manpage.

Anyway, I'll try to change float* to something that has size 4, and see if that works. I'll send you a diff later if I can get this to work. But as for completely making this transparent between 32/64 bits you should really take a look at stdint.h which defines uint32_t and so on. I don't know if there are any other headerfile(s) that are useful for this, but i seem to remember seeing a file with saner typedefed names like uint32 instead of uint32_t etc.

EDIT:
changing it to int for both DWORD and float* makes it pass that phase, but then instrument loading fails. DWORD is #defined as unsigned long which is 8 bytes on 64bit. simply changing that to uint32_t does not work - complains about loss of precision.. I fear porting this to 64bit completely would need a lot of work, for me it's not really that interesting to not be able to save songs.. anyway.. I'll try to make it load and see if my portaudio changes work.

Last edited by spctrl (2010-09-29 02:23:19)

spctrl · 2010-09-29 03:08:50

I can't for the love of me get this to work.. I'm thinking it must be that sizeof(GearStack) will be different between 32/64 bits, although it looks OK. only bool, char, int and float used there. Maybe function pointers are differing in size between 32/64 bits.. here it says sizeof(GearStack) is 280 bytes, what is it on 32 bits?

stqn · 2010-09-29 10:39:14

sizeof(GearStack) is 148 on 32 bits.

struct GearStack
{
    gear_instrument *instrument;
    gear_effect *effects[32];
    ...
};

There are 33 pointers, so 33*4=132 more bytes on 64 bits, which makes it 280 as you said.

Sigh... The whole source code needs serious work.

spctrl · 2010-09-29 10:42:41

it needs a new format basically. this will never work on 64bit

EDIT:
That sounded a bit too harsh, I am still grateful you took the time to port it! I just wish the original author hadn't been so dumb^Hnaive when he designed the format. Now sometime, when I have the time I might look at it.

Last edited by spctrl (2010-09-29 11:18:39)

stqn · 2010-09-29 12:32:57

Please send me a link to your source code, so I can integrate your changes and see what I can do to make it work on 64 bit! A plain tar or zip or whatever archive on any file host will do. You could also attach it to the bug report on bitbucket I suppose.

Portaudio v19 support would be great to have too! Don't worry if it's not working, I'll check things before (and after) merging.

spctrl · 2010-09-30 21:16:55

I have no idea if the sound actually works, but it compiles. specifically check pa_callback.h which has a new parameter (Pa_StreamCallbackFlags) which I haven't actually used inside the callback function, you might need to look at that.

http://hangar18.gotdns.org/~spectral/pav19.patch for the diff that fixes compilation against portaudio V19.
As I said, I haven't been able to try if sound works because I haven't compiled PA with pulseaudio support and I can't be arsed to shut down everything that might use the audio device.

As for my changes to the load function I haven't got them left as I gave up on it for now. the only thing i did was to change float* to int and also DWORD to uint32_t. but that won't work on 32bit (at least not the float* thing. so the best thing would probably be to look at what types are available (stdint.h, etc) and change everything to use that instead. As for the pointer problem in struct GearStack I can't really see any way around it other than reading specific bytes and putting them in the struct yourself. the best would probably be to design a totally new file format (xml maybe?) which didn't save a struct like that so there will be no problems between different architectures..

stqn · 2010-10-04 23:33:43

Thanks for the patch! I have started working on 64 bit support... I'd like to keep file format compatibility, but it's going to take time. I just spent 2 hours trying to figure out what all the kf* functions are about and it's not going to be easy . But it's doable. Anyway for now I'm just trying to understand the source code to see how I can change the loading/saving routines in a good way.

tomd123 · 2010-10-05 00:22:34

Can someone please make a aur package for this?
Thanks for this awesome contribution! awaiting a pkgbuild for further eval.

stqn · 2011-02-22 22:16:27

It took a while but I finally made the changes to use portaudio v19 and ALSA thanks to the patches provided by spctrl and drasish (from the Musagi forum.) You can grab the source or precompiled exe from BitBucket (link is in the first post.)

Initial report(s) seem to indicate that it now works with ALSA and even PulseAudio (though I'm not 100% certain about that one), even when another app is playing sound.

As far as a PKGBUILD is concerned, I've started looking into it... But it's easier to just clone the repo and type "make" . Still no 64 bit support either; it requires a lot of work.

geoisis · 2011-02-23 06:34:30

very interesting , will try asap. thanx

realitygaps · 2011-02-23 11:39:55

My quick attempt at a PKGBUILD for musagi - http://aur.archlinux.org/packages.php?ID=46822

stqn · 2011-02-23 13:10:00

realitygaps wrote:

My quick attempt at a PKGBUILD for musagi - http://aur.archlinux.org/packages.php?ID=46822

Nice. You could add "sdl" and "gtk2" to the depends. Not sure about opengl, is there a standard dependency for that or are we expecting everybody to have it? Edit: maybe "libgl".

Also you don't need to copy the playmu directory.

There might be a problem with the config.txt file too, since it is saved in the same directory as the binary, I think...

Last edited by stqn (2011-02-23 13:25:48)

realitygaps · 2011-02-23 13:32:29

PKGBUILD is updated now with the dependencies you suggested and the playmu directory removed. Not sure what to do about the config.txt file though.

Arch Linux

#1 2010-08-11 10:49:55

Musagi for Linux (chiptunes music composition)

#2 2010-08-11 11:04:33

Re: Musagi for Linux (chiptunes music composition)

#3 2010-08-11 12:03:51

Re: Musagi for Linux (chiptunes music composition)

#4 2010-08-11 18:05:02

Re: Musagi for Linux (chiptunes music composition)

#5 2010-08-11 22:12:17

Re: Musagi for Linux (chiptunes music composition)

#6 2010-08-11 22:34:23

Re: Musagi for Linux (chiptunes music composition)

#7 2010-08-11 23:20:53

Re: Musagi for Linux (chiptunes music composition)

#8 2010-09-28 22:34:26

Re: Musagi for Linux (chiptunes music composition)

#9 2010-09-28 23:03:17

Re: Musagi for Linux (chiptunes music composition)

#10 2010-09-29 00:17:23

Re: Musagi for Linux (chiptunes music composition)

#11 2010-09-29 01:22:28

Re: Musagi for Linux (chiptunes music composition)

#12 2010-09-29 01:28:29

Re: Musagi for Linux (chiptunes music composition)

#13 2010-09-29 02:09:59

Re: Musagi for Linux (chiptunes music composition)

#14 2010-09-29 03:08:50

Re: Musagi for Linux (chiptunes music composition)

#15 2010-09-29 10:39:14

Re: Musagi for Linux (chiptunes music composition)

#16 2010-09-29 10:42:41

Re: Musagi for Linux (chiptunes music composition)

#17 2010-09-29 12:32:57

Re: Musagi for Linux (chiptunes music composition)

#18 2010-09-30 21:16:55

Re: Musagi for Linux (chiptunes music composition)

#19 2010-10-04 23:33:43

Re: Musagi for Linux (chiptunes music composition)

#20 2010-10-05 00:22:34

Re: Musagi for Linux (chiptunes music composition)

#21 2011-02-22 22:16:27

Re: Musagi for Linux (chiptunes music composition)

#22 2011-02-23 06:34:30

Re: Musagi for Linux (chiptunes music composition)

#23 2011-02-23 11:39:55

Re: Musagi for Linux (chiptunes music composition)

#24 2011-02-23 13:10:00

Re: Musagi for Linux (chiptunes music composition)

#25 2011-02-23 13:32:29

Re: Musagi for Linux (chiptunes music composition)

Board footer