@jbaker said:

I can't seem to get return values from the X32. With the X32 livetoolkit software I know that sending [/ch/02/mix/on] will return [/ch/02/mix/on ,i 1]. The send command doesn't need a value type (float, int, etc.), but the return value contains an int, which is either 1 or 0, which represents the mute as on or off. I can't get any return values from the board. I'm trying UDP with netsend -u -b 10.136.124.112 10023.

I think the receiving bit should look like this:

If I send back to the same port e.g. /hi/back 1 then, after list trim, the message looks like hi back 1.

[fudiformat] / [fudiparse] is a workaround to handle the numbers in the OSC path.

BTW those "send /xxx/yyy/zzz" -- pretty sure that's not standard OSC -- I crashed SuperCollider trying to send to it that way.

This is the right way to send a properly formatted OSC message. Leading zeroes can be escaped, e.g., set ch \02 mix on, bang would send /ch/02/mix/on.

hjh

Ciao,
I have created a patch (part of which uses slicerec~ and sliceplay~ by Katja Vetter) to process the sound I create with wooden boxes to which various objects have been attached, many of them metal, one box I built myself, while others are from the company LeafAudio. You can see the patch in action in a video

The sounds created by the boxes are processed in real time, i.e. all the sounds you can hear are an elaboration of the sounds created with the wooden boxes. The music is improvised . SoundRaum is a series of videos documenting short improvisations of electroacoustic music. They were created in various locations. The first videos in the series were recorded in my studio. More videos will follow, in which I will also play outdoors in Basel. The patch is on a ‘Raspberry Pi’ computer. The sound quality is guaranteed by the ‘Pisound’ sound card. During improvisation, I decide which sound processing to use. The commands are given via the modular ‘intech studio’ grids. Of the objects I use for sound generation, I mainly use the ‘Microphonic Soundbox’ .
Enjoy

I have installation where a person makes a sound in a microphone and they hear the sound manipulated back 2 seconds later. The issue is that the mic also hears the delayed sound coming from the speaker so the sound gets stuck in a 2 second feedback loop. I'm considering workarounds involving cutting the mic gain but the ideal solution in my mind would be to cancel the sound coming from the speaker to the microphone while simultaneously continuing to actively capture sounds from people.

I played with delaying the sound using Zexy's [z~] instead of [delay~] and then subtracting the delayed sound from what the mic heard. With this method I tried to tweak the delay, considering the time it takes for the sound to travel from the speaker to the mic, but couldn't get any meaningful results. I also tried playing with this patch:
https://github.com/JosephEoff/PureData_NoiseFilter

and that did a great job removing feedback when no 2 second delay was present but it doesn't seem to be the appropriate tool for my problem.

Any thoughts or suggestions would be appreciated.

@seb-harmonik.ar "it seems like the reason is to avoid a block delay?"

I really wish he had elaborated on that.

In SuperCollider, I have an example where the InFeedback UGen produces inconsistent results depending on the evaluation order: https://scsynth.org/t/supernova-groups-threads-ndef/1915/4

This might be what MSP is thinking of: the choice is either to impose a consistent block delay (breaking backward compatibility) or to risk inconsistent behavior depending on scheduler ordering of audio objects.

What he doesn't explain is why name changes have anything to do with this.

I guess I will have to join the mailing list and ask for clarification... didn't really want to do that because I don't need every thread coming into my inbox, but that seems to be where this is being discussed.

My use case is a modular mixing framework.

You create [fader~ myCoolSynth] (using the default target name "main"). Now there are:

• [catch~ myCoolSynth-auxL] and [catch~ myCoolSynth-auxR]
• [throw~ main-auxL] and [throw~ main-auxR]
• [send~ myCoolSynth-preL] and [send~ myCoolSynth-preR] (pre-fader sends)
• [send~ myCoolSynth-postL] and [send~ myCoolSynth-postR] (post-fader sends)

Now you change your mind and you want to call the channel "lead." So you go to the name symbol box (because, in a DAW mixer, you can change the name of the channel by [double-]clicking and typing), type "lead" <ret> and the catch and send objects need to change name... but this is not supported in vanilla.

spacechild1 had suggested dynamic patching for this, and was generous enough to make dcatch~ and dsend~ abstractions for me... ext13 may be fine as well, although the mailing list thread points out that it's 10 years old without recent updates.

(but if you're dynamic patching signal objects that's the case anyways I think)

I found in practice with my mixer objects that sometimes it's necessary to reset DSP, but not always.

hjh

I am learning the basic concepts of music production by exploring the capabilities of Cakewalk by Bandlab as well as Pure Data. My question is about how to capitalize on the sounds one generates in Pure Data.

I assume that although it is possible to write music entirely in Pure Data, most producers in some fashion export sounds from Pure Data into a DAW for further arrangement. The most sensible way to do this that I can see would be to make virtual instruments out of one's Pure Data creations.

Suppose I create a sound I like in Pure Data, either using a synthesizer written in Pure Data, or by some unstructured process of playing with sinesums/drawing freehand sound waves in tables/etc. How can I make a custom virtual instrument in Cakewalk from such a sound? I found this (

) tutorial for creating virtual instruments, but it doesn't discuss Cakewalk, and the tutorial involves audio recording from a physical instrument. Would sound generated in Pure Data have to be recorded in order to be ported to a DAW, or could it be transferred through an entirely digital process, since the sound in Pure Data originates digitally?

If this is not the right way to go about utilizing Pure Data sounds in a DAW, then what is?

Hey Seb!

I appreciate the feedback

The routing I am not so concerned about, I already made a nice table based preset system, following pretty strict rules for send/recives for parameter values. So in theory I "just" need to get the data into a table. That side of it I am not so concerned about, I am sure I will find a way.

For me it's more the decoding of the sysex string that I need to research and think a lot about. It's a bit more complicated than the sysex I used for Blofeld.

The 32 voice dump confuses me a bit. I mean most single part(not multitimbral) synths has the same parameter settings for all voices, so I think I can probably do with just decoding 1 voice and send that data to all 16 voices of the synth? The only reason I see one would need to send different data to each voice is if the synth is multitimbral and you can use for example voice 1-8 for part 1, 9-16 for part 2, 17-24 for part 3, 24-32 for part 4. As an example....... Then you would need to set different values for the different voices. I have no plan to make it multitimbral, as it's already pretty heavy on the cpu. Or am I misunderstanding what they mean with voices here?

Blofeld:
What I did for Blofeld was to make an editor, so I can control the synth from Pure Data. Blofeld only has 4 knobs, and 100's of parameters for each part.... And there are 16 parts... So thousand + parameters and only 4 knobs....... You get the idea

It's bit of a nightmare of menu diving, so just wanted to make something a bit more easy editable .

First I simply recorded every single sysex parameter of Blofeld(100's) into Pure data, replaced the parameter value in the parameter value and the channel in the sysex string message with a variable($1+$2), so I can send the data back to Blofeld. I got all parameters working via sysex, but one issue is, that when I change sound/preset in the Pure Data, it sends ALL parameters individually to Blofeld.... Again 100's of parameters sends at once and it does sometimes make Blofeld crash. Still needs a bit of work to be solid and I think learning how to do this decoding/coding of a sysex string can help me get the Blofeld editor working properly too.

I tried several editors for Blofeld, even paid ones and none of them actually works fully they all have different bugs in the parameter assignments or some of them only let's you edit Blofeld in single mode not in multitimbral mode. But good thingis that I actually got ALL parameters working, which is a good start. I just need to find out how to manage the data properly and send it to Blofeld in a manner that does not crash Blofeld, maybe using some smarter approach to sysex.

But anyway, here are some snapshots for the Blofeld editor:
Image of the editor as it is now. Blofeld has is 16 part multitimbral, you chose which part to edit with the top selector:

Here is how I send a single sysex parameter to Blofeld:

If I want to request a sysex dump of the current selected sound of Blofeld(sound dump) I can do this:

I can then send the sound dump to Blofeld at any times to recall the stored preset. For the sound dump, there are the rules I follow:

For the parameters it was pretty easy, I could just record one into PD and then replace the parameter and channel values with $1 & $2.

For sound dumps I had to learn a bit more, cause I couldn't just record the dump and replace values, I actually had to understand what I was doing. When you do a sysex sound dump from the Blofeld, it does not actually send back the sysex string to request the sound dump, it only sends the actual sound dump.

I am not really a programmer, so it took a while understanding it. Not saying i fully understand everything but parameters are working, hehe

So making something in Lua would be a big task, as I don't know Lua at all. I know some C++, from coding Axoloti objects and VCV rack modules, but yeah. It's a hobby/fun thing I think i would prefer to keep it all in Pure Data, as I know Pure Data decently.

So I do see this as a long term project, I need to do it in small steps at a time, learn things step by step.

I do appreciate the feedback a lot and it made me think a bit about some things I can try out. So thanks

@flight453 i have made an abstraction for this, feel free to use as you like. velocity-senitivity.pd just download it and call it in your patch.

when you call a patch (or any normal file) in pd through directory traversing in objects, there are some rules (idk if i know all, because i have just stumbled upon them randomly):
a: to call a patch in the same directory (folder) as your main patch, just type out the name, excluding the ".pd" at the end, so velocity-senitivity.pd becomes velocity-senitivity.
b: to call a patch inside a directory which is inside the same directory as your main patch, just type the directory name for the directory inside the shared directory, then a "/" and then the filename, again, excluding ".pd", so velocity-senitivity.pd inside the directory "abstractions" which shares the directory with your main patch, becomes abstractions/velocity-senitivity. you can go as many directories in as you like, so abstractions/midi&more/velocity-senitivity
c: if it is outside your directory type one "." for as many directories you have to go outside and then "./" (yes, that is a "." followed by a "/") and then your patch name, again, excluding ".pd".
d: you can type what rule "c" says and not entering the patch name, and then type what rule "b" says. here's an example of this in action .../abstractions/midi&more/velocity-senitivity, so the ".../" means that you shold go back 2 directories, and "abstractions/midi&more/" means that you should go inside the folder "abstractions", and then "midi&more", and "velocity-senitivity" is the the patch that you want to use.
e: just typing out the full directory, again excluding the ".pd"

you'r welcome

Hello,

I am working on a Sound Installation for a special Education School. The Installation is going to be located in the Snoezel Room (a room with a soothing and stimulating environment). So the basic Idea is, that you can press a button (or another input device like IR ... still working on this) and then a "Star" (Led lights at the ceiling) turns on and a corresponding sound is heard. The light is supposed to fade together with the sound. To be able to achieve this I want tu use a Bela that runs a PD Patch and controls the LEDs. So right now I am still working on the basic Patch, that has to be PD Vanilla (because of Bela). Right now I am working with 8 "Stars" and when you press a button (right now on a midi Controller) it starts an ADSR Envelope that controls a Bandpass Filtered noise sound. You can chose different scales like Overtones, Pentatonic, .... . Additionaly I have added atmospheric sounds like water and waves/wind to create a soothing atmosphere. What I want to do now (and where I do not know how to achieve this) is:

1. I would like to integrate a Loop Function, that saves all the Input Data (Numbers and the Time when they are triggered). It should start to record the Data when the first Sound is triggered and then when there was no Input for a certain threshold (like 5 - 10 sec) it should play back the recorded Data in a Loop.

2. For the Atmosphere I also would like to add a soothing tonal drone that fits the Sound of the Scale of the Resonating Noise. I tried something with a phasor~ an long attack and release and a bit of filtering ... but it really does not sound good and soothing now. Any suggestions on how to get an atmospheric soothing slowly changing drone like tonal sound would be of big help!

@Maggie17 Sometimes it is easier with words........

Dollar $ variables in Pure Data patches.
A dollar variable is a thing that can be given a new value.
The new value can be a float or a symbol.

1. If the Dollar variable is in an [object] box
   A Pd patch can be saved and used inside another patch. We then call it an abstraction.... and it is just like a programming sub-routine.
   If you want to use it many times then you have a problem, that they are all the same, so if you put an object [receive woof] they will all receive any message that you send with [send woof].
   That might well be what you want to do.
   But what if you want to send the message to only one of them?
   You can give it an [inlet], but your patch will get messy, and what if your patch needs to make its own mind up about which abstraction it wants to send the message to, maybe depending on which midi note it received?
   The solution is to give the abstraction arguments... some parameters that define it and make it different to the other copies.
   For example [my_abstraction]
   Let’s give it some arguments [my_abstraction 5 9 woof]
   Inside the abstraction, as it is created (you open its parent patch) the dollar variables will be replaced. Wherever you see $1 written IN AN OBJECT it has been replaced by the number 5.
   Number 5 because 5 is the first argument and has actually replaced the $1. You still see $1, but if you bang a [$1] object it will output 5.
   [f $2] will output 9
   [symbol $3] will output woof
   So if you have an object [receive $1-$3] then it has now become [receive 5-woof]
   And if you want to send it a message from outside, from another patch or abstraction, you will need to use [send 5-woof]
   Every Pd patch, which remember includes your abstractions, also has a secret number. The number is unique and greater than 1000. As Pd opens each patch it gives it the number, increased by one from the last number it gave.
   That number will replace $0 as the patch is created. You can find out what the number is by banging a [$0] object and connecting its output to a number box, or [print] object.
   $0 can be used in any object as part of the name or the address, which means that a message cannot escape from the abstraction. A sub-patch like [pd my-subpatch] will be given the same number.
   But from outside your abstraction you don’t know what it will be when the patch is created, so it is not useful. (A lie, you can find out, but as it can change every time you open your patch it is not worth the bother).
   Use it to send messages within your patch [send $0-reset] to [receive $0-reset] for example, because the message is absolutely unique to its window, so you know it cannot interfere with other abstractions.
2. If the Dollar $ variable in a [message( box
   Dollar $ variables are also replaced, but not as the patch is created (drawn by Pd as you open it).
   Dollar zero $0 has no meaning in a message box. It will produce a zero if the message is banged, but that is it.
   It is a mistake, a patching error, to put a $0 in a message box.
   $1 $2 $3 $4 etc. in a message box are replaced by incoming atoms (individual floats or symbols or whatever) when they arrive. $1 will be replaced by the first atom in the list, $2 the second etc.
   So if you have a message box [$1 $2 $3( ..... and you send into it a list [3 48 lala( .....then it will output 3 48 lala
   That is not really very useful.
   But it is actually very powerful.
   Make a list in a message box........ [33 12 wav(
   And bang it into a message box [open my-track$2-$1.$3( and you will get the output.........
   open my-track12-33.wav
   Which could be just the message that you want to send to [soundfiler]

David.

This is a spiritual successor to amPd. It's much more stable and has many more features than amPd:

• reads/writes metadata to/from patches. This is done by storing the info in the form of comments, in a canvas called [pd meta] or [pd info]. If no such canvas exists, foobar will add it in the top left-hand corner of your patch.

• comes with a Win32 Dialog UI element, containing sliders, toggles, buttons, and edit-text/button combos to send messages to your patch.

  • foobar looks in your patch for a canvas called [pd mix] and uses the parameters of whatever sliders, bang objects, or toggles it finds there to give your UI controls similar functionality.

How playback works

• libpd sends a 1 to vol, then a bang to play.
  • Generally this is where, in your patch, you have an [r play] hooked up to your metro, and an [r vol] connected to a [*~ ] before your output reaches [dac~].

• the length of the song is arbitrarily set by the user.
  • This affects the trackbar's cursor visibility and ability to set a position.
  • If the length is 0, there will be no trackbar cursor. Otherwise, the cursor, when moved, will send its position in seconds to pos. From there, it's up to your patch to take that information from [r pos] and work it into song events.

• The patch will not actually stop and move on to the next track until libpd receives a bang from [s stop].

How the mixer works

• all mixer controls go inside of [pd mix]

• horizontal and vertical sliders are turned into slider controls in the UI element
  • labels assigned to sliders in the patch become labels for the UI element's slider controls. The same applies for send symbols.
  • min and max values of sliders on the UI element work in integers only, so if you want a gradual shift from, say, 0 to 1, write "gradient" in the slider's receive symbol, and the slider's range will be broken down into roughly 200+ individual steps.
  • there are currently 7 sliders in the UI element

• bang objects with no label become simple buttons in the UI
  • their send symbols will be reflected in the button's name and they will send a bang when clicked.
  • there are currently 3 buttons

• bang objects with a label assigned become message buttons
  • these have an edit text field associated with them, where you can type out any message you want and send it to the destination.
  • the bang's label is placed inside of the edit text field as a suggested message to send.
    • pure data strips commas out of labels, so I'm using apostrophes to denote where commas should go. ex: do this' then this
  • there are currently 2 message buttons, with the 'any' button being a potential 3rd.

• a bang object with a label written in the format dest : msg will be assigned to the 'any' button.
  • the 'any' button has an editable destination field, giving you access to basically any receive symbol in your patch.
  • also substitutes as a third normal message button, when the other two are already in use

• toggles become checkboxes
  • each checkbox can have a label and send symbol assigned to it
  • there are currently 4 checkboxes

• right-clicking a track shows the context menu entry Pd Player -> Load mixer.
  • basically, you can load mixers of tracks not currently playing for some potentially interesting exchanges between patches. After loading the mixer, you still need to hit the Refresh button to show the changes.

foo_pd's copy of libpd.dll contains only the externals that I needed to run the example patches. If you want your own patches to work with foo_pd, you might need to make another build using MSYS2. If you're not sure which objects aren't instantiating, foobar's console prints all of pd's messages while audio is being processed. I'll also add more externals over time.

I'll be maintaining foo_pd at https://github.com/myQwil/foo_pd where you can also find the latest builds

foo_pd.zip
Last Updated: Feb 26, 2021 3:55pm EST