@oid Thanks for your answer.
I followed your advice and spent quite some time learning a bit how Csound works - a bit overwhelming indeed.

Then I realized that I'd love to be able to play this synth when connecting my MIDI controller to my smartphone, so I tried to run a slightly modified version of the CSD file on Csound for Android, but I didn't manage to get anything but crashes. Then I tried with csound6~ as a Pd external on PdDroidParty and MobMuPlat, but externals of course don't work on these. Then I considered running Linux on old smartphones and tablets, but I couldn't properly access the soundcard without root access. Then I fell back and looked for handpan soundfonts, but I could find only 1 or 2 (for free) in a single scale.

Then I finally came back to Pure Data and realized that my best chance was to convert this Csound patch into Pd vanilla and run it on MobMuPlat.
Which I've done! yay!
I've had quite a few challenges and the sound isn't perfect yet, but it works, and I'm also adjusting a few things to my preferences. I'm also including the r_cycle functionalities to tune the Launchpad and it's a lot of fun! I might be able to spend my Sunday sitting in the grass and playing handpan on my MIDI controller connected to my smartphone
I will push it to Github eventually, right now it's still a little too messy for sharing, but if anyone passing by is interested, just let me know!
Cheers!

Hi everyone,

I've been playing a bit with a Csound handpan synth from here and I've used the r_cycle external to make a handpan with my Launchpad (the patch is not very complicated so I didn't try to make it neat, sorry!).
The csound patch maps specific MIDI notes to the synth according to a scale, and the Pd patch lights up the pads so each colored group of pads sends the corresponding MIDI note to CSound:

I'm super happy with it, but the next step is to make it configurable: the csound patch contains many different scales defined with giNotes = ftgen(0, 0, -<number of notes>, -2, <list of note numbers> ) :

; B Kurd
;giNotes = ftgen(0, 0, -10, -2, 47, 54, 55, 57, 59, 61, 62, 64, 66, 69)

; B Golden Arcadia
giNotes = ftgen(0, 0, -9, -2, 47, 51, 54, 58, 59, 61, 65, 66, 68)

So instead of editing the CSD file and changing the color mapping of the launchpad when I want to change scale, I would like to send a list/array/table of note numbers from Pd to [csound6~] via a message (and adjust the MIDI notes sent by the launchpad at the same time).
I know basically nothing about Csound, so I've read up and found examples using chnget/chnset or invalue which seem relatively straightforward to change the value of a single int variable. However I don't really have any idea on how to pass the list/array of scale notes using chnset or invalue, or if there is a better way to do it.

Maybe someone around here has an idea? Thanks for reading so far in any case

@whale-av Hmm thanks, this sounds like I might actually be better off with running parallel pd processes right from a shell script and communicating via netsend (this laptop has only 2 cores, so audio processing is all running in the same patch anyway, and controls+GUI in the other), rather than trying hard to get it working with [pd~] and possibly hit some more undocumented limitations later on...
I guess I'll try a bit more, and let's see where I end up

I think I finally figured it out!
Well, not sure it solves all my problems, but at least here is a limitation of pd~: midi inputs and outputs (obviously)! There were a few of those in one of the libraries called by mybigpatch.pd (r_cycle).

So here is my way around it, in case it might help others:

• In the main patch, capture notein and send [notein $1 $2 $3( to [pd~]:
  
• in the pd~ subprocess, capture the incoming in an abstraction ./myfolder/notein.pd:
  
  and replace all instances of [notein] with [./myfolder/notein]
• similarly for noteout, an abstraction ./myfolder/noteout.pd to use in the pd~ subprocess:
  
  and replace all instances of [noteout] with [./myfolder/noteout]
• in the main patch, replace noteout with [r noteout]:
  
• and the same thing with ctlin, ctlout, bendin, bendout, midiin, midiout, etc.

And the command line magic trick (that it took me a while to figure out) in order to replace all this easily in all pd files:
$ sed -i 's+\(touchin\|polytouchin\|bendin\|notein\|ctlin\|midiin\|midiout\|noteout\|ctlout\)+'./myfolder/'&+' *.pd, which will prepend any instance of notein & co with ./myfolder/.

Improvement suggestions are of course welcome.
Cheers!

@mtdr2012 Hey, my bug report seems to still be open: https://git.purrdata.net/jwilkes/purr-data/-/issues/672 but maybe you can help solving it over there
I've moved from Purr-data to vanilla a couple of months after that issue so I can't really help anymore, sorry ! I'm focusing less on the UI now, so whenever I need a control for a knob I just use a centered hslider instead.

Hello,

I've been working for a few months on a patch that got more complicated than I had planned, and I finally decided to split it into subprocesses to avoid audio clicks when UI elements refresh. In the past I've done it with 2 separate pd processed and osc calls between both, but I'd like to try with [pd~] instead (which I've read about bit never actually used for real).
So as a first step I'm just trying to load my whole complicated patch inside a [pd~] subprocess (with DSP on in both of course) using a simple

[pd~ start mybigpatch.pd(
|
[pd~ -ninsig 8 -noutsig 2]

It works with a simple patch in the same folder, however with the big one, the subprocess starts, loads the libraries, and immediately closes, showing only pd~: No such file or directory in the parent process' Pd console window.
I get no more details when adding -d 4, -stderr, -verbose or even -noloadbang (in case it's the patch initiation that failed).
My "big patch" will call many abstractions, initiate arrays, soundfilers and load text files into [text] objects so there are quite a few possibilities for not finding files - however the exact same patch starts perfectly from the same folder. Using the whole path to the patch in [pd~ ( also doesn't help.

Are there any known limitations to what [pd~] can or cannot do compared to the main parent pd process?

Thanks!

Also, I'm curious about the buttons you'll choose for this!
I can't mold silicon buttons or 3d-print the enclosure myself, so I may have to go for bulky arcade buttons, not sure yet.

@jaffasplaffa I recently built my first device, a USB midi footswitch with an arduino. A bit of googling led me to the awesome MIDI Control Surface library.

The main thing to be careful about IMO is to get the right board to communicate directly over USB (Micro, Leonardo, Teensy, see the documentation), otherwise (Uno, Nano) you will need a serial-MIDI converter software like hairless (with GUI) or ttymidi (command line).

For the LED lighting I took inspiration from my other commercial controllers, and set the arduino's code to light up the LEDs by sending a notein and then it off with a noteoff (if you have multiple colors or blinking mode, you can use different velocities, e.g. 36 1 1 for solid green on button 36 (channel 1), 36 2 1 for blinking green, 36 3 1 for red, etc.
You can also hardcode the LEDs status with the buttons status, but you may loose flexibility (especially when using Pd, but it may be more complicated to use a DAW if you have to set up when to light up the LEDs, not sure).

Now I am looking into building another controller with faders and knobs, and there I'll indeed also need multiplexers, as I believe that the bigger Arduino I could find had ~40pins. You will probably need digital pins for the buttons and LEDs, while potentiometers need analog pins (as far as I could understand so far, but I'm also new to this!).

In any case, regardless of how you initially program the arduino (e.g. only notein/noteout to control the LEDs), you can just decide otherwise later on and reprogram it (just like you would update a commercial controller's firmware) to change the note numbers of each button, add special modes to give other functionalities to the same buttons, this kind of things.

Let me know how it goes I'm hoping to get started on mine in 2 weeks or so.

Thank you @oid , I should have thought about that right away!
Turns out that aseqdump doesn't show any difference (NoteOn with velocity 0 is interestingly displayed as NoteOff, but it works anyway on the 64bits machine to turn off the LED).

I found one cause by chance however: If I connect Pd with the MIDI device via ALSA-MIDI, it works fine, but if I connect them via JACK-MIDI, I can't turn off the LEDs!

So when I connect PD with the controller with aconnect 130:1 24:0 it does work fine on both laptops. Not sure whether that might be caused by a2jmidid in the end, but I guess it is solved (and indeed not related to Pd!).

So, continuing my investigations, I have had no more success with [cyclone/xnoteout] and raw hex midi messages sent to [midiout]. And not better either if I start jack with -Xraw, and both laptops use the same version of a2jmidid.

Two more details:

• laptop where it works: Jack 1.9.14, 64 bits
• laptop where it doesn't work: Jack 1.9.12, 32 bits. I could try to upgrade jack to 1.9.14 but it may have to use different repositories or potentially mess up dependencies.

Hi all,

I am having a weird issue, not sure whether it is actually due to Pd or not: in order to turn on and off the LEDs of my Midi controller, I need to send it a noteon message with a velocity of 1 (turn on), 2 (blink) or 0 (off). This works very well on one of my machines with Debian 10, Pd vanilla version 0.49.0-3 or Pd-L20rk 2.15.2, by sending [64 1( or [64 2( or [64 0( to [noteout 1], however on another machine with also Debian 10, Pd vanilla 0.49.0-3, only the velocities of 1 or 2 make the LED turn on or blink, but impossible to turn it off with a velocity of 0!
I first thought that it may be due to Pd interpreting NoteOn with velocity of 0 as NoteOff, but it works fine on one of the computers.

Jack is started on both machines with -dalsa -Xseq and I run a2j -e to access the Midi devices through Alsa. If I stop a2j I can successfully turn the LEDs on and off with amidi -phw,2 -S "90 40 01" or 00". So I am ruling out the hardware/driver issue.

What else could it be, any idea anyone? I shall check the version of a2j later today, but they are both up-to-date using Debian buster repos so I doubt I'll find any difference there...

Sorry if this turns out to actually not be related to Pd, but I hope someone may be able to help anyway
Thanks!

@ingox Yeah I've tried to play around with [pd~] before (not very successful so far though), but in this case I'd be considering different patches as different tools that I may or may not want to use together, hence the idea of starting them independently.

@oid Great input, thank you so much! I'll definitely strip down my Bunsenlabs install, but it's already pretty decent out of the box. And I just adjusted the CPU governor as you suggested.
I've fixed Meterec in the meantime but I'll give Nama/Ecasound a try, looks very interesting!

@EEight Good to hear, thanks for your answer! I do start pd in realtime.
In the meantime I found meterec for multitrack recording in a terminal, which works pretty well, except that the ncurses interface blinks at every refresh. Instead of looking into fixing this I will probably focus on Pd then

with fx (delay, reverb, disto)

How do you apply the effects in your setup? are they also custom Pd patches, or is it safe to use external ladspa plugins?

single core doesn't change much for pd (since it's single-thread process)

Do you think that it is then preferable to run one single pd process with subpatches instead of several instances of pd? e.g. I already have one for the drumkit, I would probably make a completely separate one for recording and effects, and maybe a separate one for the mixer, but not sure whether the 3 pd processes would compete for CPU time?

Hi all,

I recently dug out an old Eeepc 701 4G from Asus that I bought second-hand in 2008 - 1-core Intel Celeron inside, with 4GB RAM. I have an audio interface Roland UA22 so that the setup can support realtime audio (Debian 10, RT kernel, jack with RT) with no XRuns and latency <10ms at 44100Hz/128/3. However, obviously, as soon as the CPU is expected to do some calculation, it is much less fun!

In particular I want to use a sampler for some instruments, typically a drumkit connected to MIDI pads, so I wrote a small no-gui Pd patch to load one single wav file in each of 16 clones (for 16 pads) responding to 16 midi notes. I want to keep them in separate clones so that I can assign them to different audio output. Right now it is quite CPU intensive, so I will have to add [switch~] and volume ramps to turn on dsp processing only when the midi note is played and hopefully without clicks.

Further in the workflow, Non-Mixer and Non-Timeline work great for a few tracks, but if I try to record several tracks for several of the drums audio outputs at the same time then the poor laptop is struggling.

TL;DR: Long story short, I'm considering using less fancy mixer and audio sequencer, i.e. command line or Pd patches with no or very basic GUI (no live GUI update as I record for example), BUT I would like to be able to occasionally use some audio effects (reverb, delay and such). Before I get into that, do you guys think that such solution would be bearable for the brave eeepc? Would other languages be more efficient than Pd on this machine?
Or (this is not the right place to ask, but I try anyway) do you know terminal-based utilities that could fulfill this otherwise? I'm thinking of a ncurses mixer similar to alsamixer, or an audio sequencer in the style of CuSE, which would be awesome.

Thanks!

Hi all (and probably most relevant to @jancsika),
I noticed today that Purr-data 2.13.0 systematically crashes when I try to save a patch with an [mknob] in it. Counts for patches that used to work with prior versions, as well as empty patches started from nothing with only a [moonlib/mknob] in it ("Save as" opens the window, but the actually saving crashes and the .pd file is 0b big). I seem to have the exact same issue on OpenSuse 15.2 and Debian 9.0 with the packages hosted on OBS (the Opensuse one says

$ > purr-data -version
Pd-L2Ork version 2.13.0 (20200802-rev.70066071)
compiled 12:00:00 Aug 24 2019

Not sure if it is a real bug that I should have reported to Purr-data's Gitlab page, if it is known already,or if I should use another knob or anything?

@beep.beep Thanks so much! I will look into all that and test and implement stuff, and I'll come back here if I have more questions!

@Tombot7 Thanks so much, very interesting. My looper's approach is however very (very) different from yours, since I took inspiration from midi loopers such as Seq64 or "matrix-based" (not sure what the proper term may be) audio loopers like Luppp, launching the clips with a midi controller with the same matrix of 8*8 buttons. So far using only audio input (from mic or [fluid~]) but I plan to include some MIDI sequencing at some point, at least for CC automation.
My first attempt included graphical visualization of the waveform and resizing of the array, but I quickly gave it up!
Interesting considerations about tabplay vs tabread4 and line~ vs. phasor~, I'll just trust you and implement this right away . I figured that tabread4~ may be handy in case of changing the tempo after recording arrays, but I guess that's something one may not even want to design for on modest hardware.
Thinking about it, I should probably consider removing [fluid~] from my main dsp patch and put it into a [pd~] subpatch, or (if it makes any difference?) yet another separate Pd instance.

Well well, this thread is giving me enough work to fill another Covid lockdown - I'm in Spain

@beep.beep Very useful, thanks again! Note that some of the glitches I hear (like the one I mentioned with the emoji window) can be heard also when Pd is not running at all, so while I'm certain that a higher delay will help, the root cause is somewhere else I will try.

Good advice on the discontinuities. I was kind of hoping that [phasor~] would handle this better than restarting [line~] from 1 to 0, but I suppose that it also just jump from 1 to 0? I've seen other discussion threads about windowing, involving for example interpolation between the end of the array and its start when beginning a new ramp with [line~], but I'll probably have to quite some time to get this to behave properly.

More questions though :
In your example, you record the ramp up and ramp down into the array itself, right? Is that not audible when looping the same array over and over? Thanks to this ramp in the array, I guess that [tabread4~] may not click even if started without a volume ramp in, would it?

Haha, sure, with pleasure to join forces @Tombot7 ! Not sure what the best way to communicate may be - I'll definitely be back on this forum if you post something, and I have a github repo with the latest more or less usable code.
Latency is not a very big deal for me however since I start playing the tracks as per the main metronome's beat, and I'm not overdubbing but I'm interested to see what you've got anyway!

@beep.beep I actually haven't seen [pd~] before, thanks again! Since DSP needs to be running, I'm not sure how I can actually use it (if I had my 64 tracks as [pd~] subprocesses, they would all have to be "DSP on"), but I'll keep it in mind. It might be more efficient than OSC messages between several DSP instances of Pd, but my machine only has 2 cores anyway, so I'm not sure whether there is much more to optimize there (for now - at some point I might very well be using my patch on other computers, and other people may use it).

I'm now in the process of implementing [switch~] in the different subpatches of my track abstraction, so as to shut off [tabwrite~] when playing and shutting off [tabread4~] while recording, let's see how this goes.

In general, I still hear quite many clicks and glitches when playing, when the [phasor~] reaches 1 and jumps to 0, or just randomly in the middle, even when the DSP instance runs in -nogui, without debug or verbose and without printing OSC messages. Increasing the number of frames per period in Jack from 128 to 1024 doesn't really help. Not sure whether this can be a problem of CPU power or sound card, I may try on another computer to figure it out - I'm on a 10-year old laptop using the embedded sound card (funny thing, I also hear tons of clicks and glitches when opening the emoji panel to write this message, so I suppose it really is a hardware shortfall).