I’ve been working on my first patch for a while and I ran into a problem today that I haven’t been able to solve. When I’m in the graphical environment my patch loads and runs fine, but when I load the patch in normal mode - w/o running startx - the patch never fully loads and I get no sound through the Organelle. I see some of my screenline text on the OLED, so I know the patch begins to load, but the VU meters never appear and the audio never comes through.
This is a new issue - previously, the patched worked in normal and graphical mode, so it is tied to some changes I made today, but if it works in graphical mode, it should work in normal mode, correct?
I am using several longer samples, and large arrays for recording, but those were present and functioning before this issue cropped up. The big change that I made prior to the issue was building a routing mixer for sends/receives using throw~, catch~, send~, and receive~ objects. I wouldn’t think that those would be incredibly resource-intensive, but the patch is getting pretty big so maybe it was the final straw. I’ll experiment with the buffer size after I get off work.
I’m not using any externals except for [arraycopy] which seemed to be working without the GUI before.
Possibly related - I’m also noticing that when I load it up in GUI mode, it takes significantly longer (several seconds) for the patch to fully load and display as compared to other patches. Some of my initialization actions tied to loadbangs that used to work no longer happen - the loadbang occurs, but not everything downstream of it executes. I solved this by putting a [del 500] after the loadbang and now everything initializes correctly. Is it possible that the loadbang is firing before the patch is completely loaded?
Thanks! Based on reading your thread I’m betting I could solve this by staggering my array initialization - I’m instantiating about 20 80 second arrays and loading about 20 similarly long .wavs into memory all at once. As per thetechnobear’s advice in that thread I should probably look into streaming the .wav files from disk rather than loading them into memory.
I agree with @thetechnobear my experience is IF it is open when you are working on it and it seg faults it’s wanting more resources than you have on the organelle unfortunately
It happened to me with the port of the Tokyo Sampler – super fun and crazy so i added a bunch of samples to it but it wont load in perf mode
Does that seem unreasonable? a single 80 second array would be 44100 samp/sec * 80 sec * 16 bits/sample = about 7 MB, right? Even with 20 of those the total memory consumed would be 140MB, which is just over a quarter of the Organelle’s available RAM. I’m not really doing anything other than routing and playing back these files. In broad strokes, i’m trying to make a multi track looper that also plays synced backing tracks.
For track playback, I assumed performance would be best if everything was in memory (as long as I’m not consuming so much ram that I’m bogging the system down) - I wanted to avoid the potential of a glitch when the file is accessed from the drive as this happens mid-song frequently.
i don’t think so. i think if the files are playing without being loaded into memory you should get resources – I think if it’s in a table you will get accuracy for sure but it might not be what you want memory wise, I always feel that if i am going to do operations on a sound file like FFT/slicing etc it needs to be in a table [unless its an FFt based effect of course] but playback of samples can just be waves with an playsf~
i am making a patch that loads big playback files for a client so i will double check because i rarely do jsut playback so i dont want to lie to ya
Ok - using restart-mother.sh to see the error on load, I get this:
timeout: Patch did not return patchLoaded, will assume its loaded
patch loaded
send patch config
using config /usbdrive/patch_loaded.sh
Connection failed (Invalid argument)
Connection failed (Invalid argument)
Cannot allocate memory
Through trial and error I found that if I reduced the array sizes on my loopers from 2.7e6 samples to 100 samples, it would load no problem. I changed the default array size to 100, then staggered my initialization so the patch loaded up, delayed, loaded the track .wav files, delayed, then resized the looper arrays to 2.7e6 samples in small groups at a time. This got the patch loading in nogui mode, but I was experiencing crackling in the audio. I changed the buffer size to 10ms in pd-opts.txt for this patch and the crackling is gone! Success for now!
My fundamental problem is that I created and tested my looper and track player abstractions on the Organelle, then switched to my computer when I discovered mother-desktop. I then created a larger patch that features many instantiations of my individual abstractions but only tested it on my laptop and in gui mode without checking in on nogui for quite a while.
I’ll look in to refactoring my track player so it streams from disk rather than loads into memory later but I appreciate the suggestion. If this current method works, I’m going to go with it for now as I semi-commited to a show using my as-yet-unfinished looper in 3 months. Elegance will have to take a backseat to functionality until I’m a little less panicked!
