GUI performance better than non-GUI?

I’ve got a sample heavy patch that only works once the desktop GUI has been loaded by typing startx. If I try and launch without the GUI my Organelle freezes.

Any idea why this would be?

You will probably have to post your patches.

Maybe some kind of stack overflow with until or infinite feedback loop?

I’ve put the patch onto dropbox, appreciate it if you (or anyone!) could take a look. I know I am getting close to the RAM limit but instinct would suggest that if it were to run in one over the other it would run in the non-GUI environment rather than with the GUI running.

You could probably use your own samples but best to check against the exact same patch that I am running. I am running the latest Beta OS.


I could drop a voice or two but 14 voices perfectly matches the white keys on the Organelle and therefore gives a really usable interface. :sunglasses:


gui mode runs with a larger buffer , so pd takes less cpu to process your patch than when in headless mode.
(of course running the gui takes cpu cycles)

tip: if you do not startx. but instead type


then you might get some more information when you launch your patch.

basically, PD is probably crashing, and sometimes the console gets a few messages about whats wrong… though honestly, PD is not very good at error reporting… so usually i end up having to alter the patch, to see where the issue lies

note: running close to RAM limits is a bad idea :wink:
the reason is, the operating system also uses ram for a temporary file system, if you fill that up, then things can go awry quickly. the organelle has 512k… i cant remember how much of thats used by just the OS/PD , but be generous.

1 Like

Not of much help… @ghostly606
Running headless right now; Menu does come up but audio is cut, seems Pd crashed.

Swapped samples but same thing though …

ok, so Ive taken a look…

your running out of memory… and then PD will crash pretty randomly… then what happens, as i said above, the OS can also potentially crash if it runs out of RAM to run. (see notes below)

this means you lose network connectivity, access to the menus and so have no way to shut it down cleanly.
(if you restart mother from the console as i discussed above, then you will see the error yourself)

Im not sure why it worked for you in the GUI, it didnt for me… in fact this is when it killed the whole OS :wink:

im not sure why your system corrupted, that shouldn’t happen unless you make the main partition writeable, but you should never need to do this.
(so whilst my Organelle crashed, no damage was done, as i could just reboot)

ok, further evidence of this, the patch works perfectly ok, on my ‘upgraded’ Organelle, because it has 2GB rather than 512kb memory.

this also shows when fully loaded the patch takes about ~220MB of RAM, this doesn’t seem too bad, but perhaps soundfiler is taking some extra memory whilst loading the samples - anyway doesn’t really matter, in practice the vanilla Organelle is not going to load this in.

so where from here?

you could try two things… which might help

  • staggering the loading, ie. load the files one after the other, rather than all at startup in one go
    (if soundfiler is allocating temp storage per load, this will mean you only use that extra storage once)
  • cut the files down to the maximum size that can be allocated - soundfiler is already warning its truncating them, but perhaps it allocates some temp storage based on file size… which is ~600MB!

as i said, its might, but Id have to go check the soundfiler source code to really see the issue, and I dont have time for that - sorry.

honestly though, Id say loading big files into RAM for playback is not, generally, a good way forward.
personally, if i was doing this id be looking to stream from disk - and/or perhaps just loading chunks of the audio file into memory at a time. if this is done well, you’d probably get pretty reasonable latency.
unfortunately, I don’t know what solutions are out in PD land to do this… so cant recommend a solution.

side note

its a pretty common weird things to happen if you run out of memory, as it creates a ‘race condition’. i.e. each time you run the offending app, it will crash in different place, so the behaviour is inconsistent, except it usually will crash (not always though, depends which code it hits)
its also why the OS can go down - the offending app can take almost all the memory, and just at that moment the OS needs some - and it tries and bang something dies.

the OS (and applications) should theoretically be coded to avoid this (and things like the kernel are) , but its not something that is often tested much as
a) OS’s virtualise memory… so you don’t run out
(the Organelle doesn’t because this reduces audio performance)
b) if you run out of memory , there frankly is not much you can do about it … other than stop what your doing.
c) its a pain to test, for such a rare case

@thetechnobear Thanks so much for looking into this and explaining how things work.

I want to avoid having to trim files in advance and I need to jump about the files (and eventually change pitch etc) which, unless I’m wrong, can’t be done when streaming from USB. Moving forward, I therefore think the best thing is to stick to a reduced number of audio files (I’m thinking 10 so can switch between them using all the “black” keys).

Once I’m back up and running I’ll make some changes and update this thread.

How is it possible to find this out?

Thanks again. :smile:

yes, this can be done when streaming…
when you read a file off a disk, you supply an offset to read from, thats how streaming works… its constantly updating the offset… essential you read chunks of N bytes in advance of use.

of course, you dont get something for nothing… so your ‘patch’ has to decide whats important to have immediately accessing (in RAM) and what its will to take a small pause for (to get the initial audio buffers worth of data) … this is ‘patch dependent’ i.e. no general rules , but for example your station switch could be possible.
… changing pitch is not an issue, assuming your just gonna speed up the phasor, thats just how fast you read the buffer.

of course, there are many strategies… e.g. you could have sets of stations, say 5 , which you can load from the patch… that way you dont have to have a huge number of stations loaded, only the ones you are using currently for a ‘performance’
… this is why you see things like ‘kits’ in Elektron gear - its a way of letting users have access to a big media library, but reduce the amount of memory used to what is required for the performance.

I want to avoid having to trim files in advance

perhaps look for a tool that can do it form the command line… there is no reason to have to do this manually.
anyway, my point was to try it… to see if it makes a difference, theoretically if soundfile is any good, then it wont make any difference anyway.

also consider format, do they need to be 32bit? perhaps given the nature of radio 16 bit is enough.

if on the command line you run ‘top’ it will tell you for each process how much memory its using, and also the overall amount.