HomSpace Forum

(31-12-21, 00:30)hansehv Wrote: [ -> ]Hi Bryan,
Well, I think you could use the internal midi through of the PI and route the midi through of samplerbox to that.

Code:

keyboard -> samplerbox with through enabled for port14 -> alsa through (port14) -> PD reading 14

We'll have to sacrifice the internal midiplayer which is not a big loss in this case imho (just a choice depending interests / usage approach of SB which differ a lot, again imho). Background: the smfplayer is a separate thread writing to alsa midi through (port14), which in turn is opened by samplerbox as input. I'm suggesting to do the opposite here..
Perhaps I can help you (& even should in order to keep your extension compatible with future development) with the samplerbox part. For the PD it means you'll have to open port 14 similar as what samplerbox does for the smfplayer. You may have figure out the specific way for opening the alsa through port in PD.
This way you leave detection of the midi input to samplerbox and get  a CC of that in PD.
Please feedback whether we're on same page here, so I can start thinking of making the SB part.
Hans

This makes the most sense to me, as samplerbox is very good at auto detecting midi controllers, and I believe there's a way for me to include a connection to a known controller at loading in PD (so port 14), what I read about it was a bit confusing but I'll figure it out. The midi player is not a big loss to me because I prefer to work with external sequencers anyways

back on running Pure Data headless, I've created a simple startup script, and added its path to rc.local, but that doesn't seem to have worked (I suspect it is trying to start before samplerbox) but the below script works if I manually call it up in the terminal after boot   maybe someone has a better suggestion for starting a script at boot or why this isn't working


this will boot my 'main' pure data patch, which will operate as a mixer for combining samplerbox with various sub patches, ie. it takes the output from the first audio card, processes it through PD, and sends it out to the second audio card. In it's simplest form the Pd patch connects the [adc~] and [dac~] objects to each other, simply passing audio through, and also includes a message to start the dsp at load. My current patch also applies reverb and adds a simple sine wave synthesizer voice, but this is just a stand in to let me hear everything working. This 'main.pd' patch will serve as the main architecture behind whatever sub patches I create in the future. I'll provide more details on creating pure data patches in future posts, along with the major setup changes that go along with the latest build of samplerbox (it is now far simpler, thank you Hans!) 

you'll notice that I connect my midi controller by name, this is a bit of a workaround solution until Hans is available to help me disable the internal midi player so that I can use the midi through port as a sort of permanent auto connect as discussed above in the thread.

I didn't want to touch this until the new build of samplerbox was complete, but this was such a simple step that I had done before (for detailed instructions I used https://guitarextended.wordpress.com/201...pberry-pi/ for reference), I figured I might as well start experimenting.

I recently got in the mail 4 rotary encoders and 4 slide potentiometers, I need to start breadboarding and programming the arduino midi controller component. Any patch used in Pd will have these 8 controls at their disposal (and will be built with that in mind).


on a performance note, pure data, running headless and with reverb and synth voice, sits at around a stable 10% of cpu usage, and runs on a separate core from samplerbox.py

For those following I have been updating this thread so that the instructions match the latest build and the switch to a hardware audio routing solution.

I haven't thought about this in awhile, mostly because it failed to generate the kind of interest I thought it would, but my work is soon getting a UV printer, which should allow me to easily print pretty decent circuit boards for etching, as well as nice graphics for faceplates and the like, so I've been musing on this project again. I had originally planned on using an arduino to create a MIDI control surface to be embedded along with the Raspberry Pi, including 4 push encoders and 4 slide resistors, but along with the two sound cards this ends up being a lot of hardware to shove into one box (not impossible, just messy and big). 

I recently learned about the Daisy Seed microcontroller , which is SMT32H7 based, has  audio in and out, USB Midi, and can run on arduino code, C++, and compiled PD, as well as having it's own DSP library. I don't know how complicated of a patch it can handle, so there are probably some pretty big processor limitations compared to running pure data directly on the raspberry pi, but there's a lot of potential here, and as a dedicated processor probably more stable and reliable. there's also the potential to add a second display dedicated to what's happening on the daisy. The only downside of pushing audio processing to a secondary board is that you lose immediate testing of patches/code, as it has to be flashed to the microcontroller, but pure data patches and other code could still be written on the Pi itself, keeping all coding self contained.

I still think this project, of creating a flexible audio environment to run alongside Samplerbox has a lot of potential as an instrument

I guess the task ahead of me is to get a Daisy Seed to experiment with audio processing and hardware controls, and then to design a carrier board for the pi, microcontroller, OLED, encoders and slide resistors...

(17-05-22, 19:26)bbishop Wrote: [ -> ]I haven't thought about this in awhile, mostly because it failed to generate the kind of interest I thought it would, but my work is soon getting a UV printer, which should allow me to easily print pretty decent circuit boards for etching, as well as nice graphics for faceplates and the like, so I've been musing on this project again. I had originally planned on using an arduino to create a MIDI control surface to be embedded along with the Raspberry Pi, including 4 push encoders and 4 slide resistors, but along with the two sound cards this ends up being a lot of hardware to shove into one box (not impossible, just messy and big). 

I recently learned about the Daisy Seed microcontroller , which is SMT32H7 based, has  audio in and out, USB Midi, and can run on arduino code, C++, and compiled PD, as well as having it's own DSP library. I don't know how complicated of a patch it can handle, so there are probably some pretty big processor limitations compared to running pure data directly on the raspberry pi, but there's a lot of potential here, and as a dedicated processor probably more stable and reliable. there's also the potential to add a second display dedicated to what's happening on the daisy. The only downside of pushing audio processing to a secondary board is that you lose immediate testing of patches/code, as it has to be flashed to the microcontroller, but pure data patches and other code could still be written on the Pi itself, keeping all coding self contained.

I still think this project, of creating a flexible audio environment to run alongside Samplerbox has a lot of potential as an instrument

I guess the task ahead of me is to get a Daisy Seed to experiment with audio processing and hardware controls, and then to design a carrier board for the pi, microcontroller, OLED, encoders and slide resistors...

This sounds sooo good! I'm a newbie in samplerbox, but got one working an running nicely. It will be awesome to have PD included!
Looking forward for advances in this subject! Thanks for you time and effort in heading this idea!