26-05-21, 02:16 -
Hi Hans!
Thanks for the reply, I wasn’t able to respond till I got home from work, but that gave me plenty of time to think things over.
Actually testing the limits of samplerbox by cranking the chord and arpeggiator on my controller was the first thing I did when I got it going, very pleased with what it was capable of!
I’m probably going to reduce polyphony to lower the chance of peaking no matter what, but I’ve been using this as a bit of a benchmark as I test things out.
Until I have the audio configured for pure data it’s hard to tell if it’s actually working, but with the midi controller properly connected (or, as far as I can tell...) and testing the limits again samplerbox seemed to peak at the same range while pd stayed static (maybe moving 1-2%), from what I can tell it’s the overall complexity of the pd patch that determines the cpu it demands, and not what midi is currently making it do, so that’s promising! Obvious limits of the type of patch I can build but it would also make testing a lot easier.
I understand that it’s the sustained release of notes layering on top of each other that causes the cpu peaks in samplerbox (all those wav files playing on top of each other), I believe you’ve mentioned elsewhere that reducing polyphony using reverb to simulate sustained release is more efficient. In pure data it might be possible to have an envelope follower control the level of reverb (increase it at the end of a note), for a more realistic simulation, but pd might end up demanding too much.
After more reading up today (when I should have been working
) I found out that alsa loopback (instead of jack)might be the better option for routing audio between the two programs, I should be able to just set the audio-out in the samplerbox configuration file to the virtual alsa port, and same with audio-in in pd... I’ll find out later, I’m going to load the new OS build and start fresh!
Using two boards is definitely a possibility, although having a nice way to power both in a single case becomes a bit of a problem. My heart is not set on this all working on one board, but if it does it greatly influences my case design and the number of hardware controls I include (I work as a sign maker/engraver/CNC operator so custom case building is more of my area of expertise).
I think if it ends up requiring two pi’s I’ll just make a separate instrument just for pure data, which I might do anyways, but leaning more towards as a “music computer“ like the organelle or op-1 (but with more knobs and no built in keyboard)
Also in my research today I found this compiler that converts pure data files into more efficient c/c++, which might be a necessary step to keep it resource friendly.
https://github.com/enzienaudio/hvcc
https://www.rebeltech.org/2018/09/12/com...-compiler/
Thanks for the reply, I wasn’t able to respond till I got home from work, but that gave me plenty of time to think things over.
Actually testing the limits of samplerbox by cranking the chord and arpeggiator on my controller was the first thing I did when I got it going, very pleased with what it was capable of!
I’m probably going to reduce polyphony to lower the chance of peaking no matter what, but I’ve been using this as a bit of a benchmark as I test things out.
Until I have the audio configured for pure data it’s hard to tell if it’s actually working, but with the midi controller properly connected (or, as far as I can tell...) and testing the limits again samplerbox seemed to peak at the same range while pd stayed static (maybe moving 1-2%), from what I can tell it’s the overall complexity of the pd patch that determines the cpu it demands, and not what midi is currently making it do, so that’s promising! Obvious limits of the type of patch I can build but it would also make testing a lot easier.
I understand that it’s the sustained release of notes layering on top of each other that causes the cpu peaks in samplerbox (all those wav files playing on top of each other), I believe you’ve mentioned elsewhere that reducing polyphony using reverb to simulate sustained release is more efficient. In pure data it might be possible to have an envelope follower control the level of reverb (increase it at the end of a note), for a more realistic simulation, but pd might end up demanding too much.
After more reading up today (when I should have been working
) I found out that alsa loopback (instead of jack)might be the better option for routing audio between the two programs, I should be able to just set the audio-out in the samplerbox configuration file to the virtual alsa port, and same with audio-in in pd... I’ll find out later, I’m going to load the new OS build and start fresh!Using two boards is definitely a possibility, although having a nice way to power both in a single case becomes a bit of a problem. My heart is not set on this all working on one board, but if it does it greatly influences my case design and the number of hardware controls I include (I work as a sign maker/engraver/CNC operator so custom case building is more of my area of expertise).
I think if it ends up requiring two pi’s I’ll just make a separate instrument just for pure data, which I might do anyways, but leaning more towards as a “music computer“ like the organelle or op-1 (but with more knobs and no built in keyboard)
Also in my research today I found this compiler that converts pure data files into more efficient c/c++, which might be a necessary step to keep it resource friendly.
https://github.com/enzienaudio/hvcc
https://www.rebeltech.org/2018/09/12/com...-compiler/