I made a patch, with a subpatch, where the subpatch processes a pix_image by pix_kaleidoscope. The subpatch contains animation for some of the coordinates, etc.

Then I added a second copy of the subpatch, to produce a different image as an alpha mask.

Then I added a third copy, to produce a background animation over which the first subpatch should be overlaid, with transparency.

After adding the third supatch, the first one stops animating.

I'm not using any named send-receive pairs here. There should be no naming conflicts.

Is there a limit on the number of pix_kaleidoscopes in a patch?

I have tried to rebuild this patch multiple times, and every time, it fails in the same way.

I'm getting frustrated. I'm sorry but I've been working on this demo for class for SIX HOURS and it still isn't working. It's 9:30 pm. I have to give up.

I don't like giving up.

hjh

stopped-animating-why.zip

@Nicolas Danet Thanks for the tip, I didn't knew about Perf on linux it's very handy. I ran a test on each patch/subpatch and got the following:

So I will serach about -GI__printf_fp_l _IO-vfscanf vfprintf plus_pcrf8 and delay_tsc to see to what they match in PD. But if GI_printf and vfprintf are calls used by PD for the GUI object then @alexandros was right and I will replace all GUI object by text ones.

@EEight My problem with switch~ is not that I don't know how to use its syntax but more because splitting each sound processing patch in my patch would divide it into at least 16 different subpatch(probably more). And as far as I experimented the pd~ object I have noticed that running 9 subpatches took more ressources than just running 3. Considering this I'm not sure that implementing switch~ to my patch will introduce a significant gain of processing power. And it is the case it would be effecient if I only used few tracks out of the 8 track grroovebox that I'm working on, disable Fx ect.. and as soon I want to use the full capabilities of the patch it would crash because all the audio processing patch would run with the DSP and the CPU performances would rise again to what I got now.

Maybe I didn't explain it very clearly, so I will rapidly explain it again. My main problem here is that my intitial patch(we'll called it v1) uses 10-12% of CPU, and my motherpatch for different processes(let's call it v2) uses 18-20% + subpatch 1 running at 12-15% and subpatch 2 8-10%. So I got a v1 is runniingn 50% on one core and V2 and its subpatches is running at 30-40 with peak at 60% on four cores. Which is kind of the worst optimization of the history of computing ^^. Though ginving the Perf result I have something to investigate to see where the problem come from. I'll give you update as soon as I found out what to do.

EDIT: I did a bit of search it seems that IO-getc, GI-printf, IO-vfscanf and vfprintf are all functions used to manages stram of data. I'm not sure but I'm sending the value from my GUI/input patch to my auddi processing patch via netsend, maybe the way I'm doing it is not optimal, maybe I should switch to osc~ because it's more effective to stream large numbers of value. Maybe I messed up the way to through values into the subpatches(because if my netsending method is messy it does not explain why I see the same problematic function calls in the subpatches). It coould also be link to the GUI elements since data streaming could be used in in those. But it does not explain why there's the function call in my mother patch that isn't using any GUI elements. To get better result I will find directly in PD source code.

EDIT 2: I found vfprintf in this PD source file "pa_debugprint.c" so it don't validate the few hypothesis I made before, but in my pd window I got repeated messages like "output snd_pcm_delay failed: Unknown error 476 astate 3" they could be the reason of this. Then I also found plus.perf8 here "d_arithmetic.c" it seems relied to operators (/ * = -) I use them to set value to my synth ect... so getting rid of them would be very difficult if not impossible.

@dom1817 You can use a canvas to display dynamic text from a parameter object like a hslider so that you cannot modify the value but just read it (your canvas is like a screen that just shows your number). You can change the value in an indirect way by using the hslider in your GUI. The advantage of this idea is that you can have many parameters values and all of them can be shown into just one small canvas object saving a lot of space inside your GUI. Having a lot of number boxes inside GUI is not a good idea to show parameters values. The disadvantage is that you need to put more code into your GUI.

You can check this module that i made. It contains a feedback monitor screen for reading parameters. See the small "wave_sweep<-0.61" canvas in the imagine. It shows the values of the sweep hslider.

WaveMaker patch download :
WaveMaker.zip

Here is a more simplified version to show how to do it :
ParameterFeedbackScreen.zip

OBS ! the "$0-clear-send" names come from right-click on each objects and set under "Messeges" the "send symbol" and "receive symbol" so that you don't need to use wiring between GUI objects. The "send symbol" is the output of that object and the "receive symbol" is the input. the "$0" symbol is used so that you can have the same GUI multiple times in the same patch without problems. You can also change in "label p1-$1" like "label Value:->$1" so in canvas will look like "Value:-> [your parameter value]" for aesthetics purpose.

snapshot :

That was the problem, all is well and the data is filling the array exactly as expected. Regarding the sysex, this message is a single complete sound, each number between F0 and F7 is a parameter in the synth and indexed just as the array is, 1 is VCO1 Octave, 2 is VCO1 semitone, 3 is VCO1 detune and so on, so the plan is just to set the receive symbol on a [nbx] to correspond to its parameters spot in the array, n1, n2, n3, etc, then the counter stepping [get array] and [pack] to get the full symbol and data for [send] to send off to the [nbx]s, seems simple. The data sent to the synth will be as CCs and short single parameter sysex messages, parsing the full sysex for the sound just seems so much more sensible than sending 350 or so individual sysex parameter requests.

7F is just every parameter I have set at full in that patch A few Dozen of the 00s are reserved bits used internally within the synth though, it is not quite all fun stuff.

Thanks for your help!

Hi, I'm trying to use LADSPA plugins in my patch with [plugins~] which I have installed through /help/find externals/
I have the plugin: L/C/R Delay loaded correctly using [plugin~ lcrDelay] and it is showing as loaded in the print window. Now i'm wondering how to interface with the parameters of the delay. From what I can see so far I use number and message box chains on the first inlet stating the value (first) and then the parameter name (second). is this correct? Also.. how do I find a list of the correct parameter names and their corresponding value ranges for each plugin?
Thank you
the setup I'm trying looks like this: -

[ \ <- parameter value
|
[mix] <- example of parameter name
|
[plungin~ lcrDelay] <-LADSPA object

@solipp Maybe I'm missing something but as far as I can see, [savestate] just saves a bunch of lists to the parent patch and links those lists to the instance that sent them, so that when you open the parent patch again each instance of the abstraction gets back its respective lists. But there is no built-in way to associate each list to the corresponding parameter, and whenever you open the parent patch each instance of [savestate] that you have in there receives all lists relative to that abstraction. How do you parse those saved lists? I think you have to either pack/unpack your parameters into a single list like in the help file, with each element of the list being a single parameter (which doesn't seem practical to me, especially if you want to save variable length arrays and text), or you can create one list for each parameter, but in that case you need to attach some sort of identifier to each list so that you know how to parse them. Something like this:
Which is exactly what I did, except that by making abstractions for this mechanism you don't have to copy/paste/rename it every time you add a new parameter to your abstraction.

Am I missing something? How is everybody using this object?

I am using the obj from the pd messages listed in https://puredata.info/docs/tutorials/TipsAndTricks#undocumented-pd-internal-messages to create new subpatches on fly. Inside of my subpatch i have a loadbang which should send a bang write on creation, but it omits no bang. I am sure this has to do with using the obj message, since creating a new subpatch instace per hand i get the loadbang.

This is how i create the new subpatch instances (apple):

And inside each subpatch:

I am working on using a pd patch to send MIDI sysex parameters to control a Kawai K1r synthesizer parameters. My current patch is working however I would like to make my code more "resusable",

My patch consists of a slider with an outlet to a int object that converts the slider value into a whole number, then out to a message object that contains the complete decimal code for the sysex message. I have a $1 at the position where the parameter value should change, so the int object value is inserted into the message string at that point. Then the message is sent out to the midout. I am able to use the slider in my PD patch to change the value of a parameter and see and hear the changes from the synthesizer. My patch currently has 1 slider.

I intend to set up sliders for many parameters, and would like to avoid copying the full sysex message for each slider. It would seem preferable to store the "header" of the sysex message as a constant or global variable and build the sysex string by concatenating 3 or 4 parts; the header, the parameter number, the parameter value and the end of message.

Below is an example message in decimal values:

240 64 0 16 0 3 15 0 $1 247

Reading this left to right, I only need to change the 7th and 9th values in the sysex string. How do I go about doing this in PD?

"The PD trees sometimes bear unexpected fruit."

The zip below includes 29+1(raw) standardized effects (esp.) for use with MobMuPlat.

mmp_effs_collection.zip

They all work and have been standardized in the following manner:

1. all are MMP-compliant (so include only objects which MMP supports)
2. have 3 inlets and 1 outlet~
3. the inlets are (from left to right): the incoming signal (i.e. inlet~), the parameters(3), and a switch~
4. the effects have all been finessed to only include <= 3 parameters
5. the parameters are sent to the second inlet via [0 $1(, [1 $1(, and [2 $1(
6. the switch is a toggle so 0|1
   and
7. each window is 186x116 pixels.

I have included an .mmp file to listen to and test them with either adc~ | randomnotes. It also includes a bypass toggle , three parameter knobs (which load the parameter name to each label once an effect is chosen), and a gain. Only the selected effect's switch is turned "on" so it is very low on the cpu.

The MMP file, in and of, itself may prove useful to someone as it packages in a single place a 30-effect "pedal-box".

That however is not why I am sharing it.

Since the effects are standardized and mmp-compliant, my hope/thinking is others may include them in their work no matter what it may be and thus build their patches, apps, etc., using the effects as building-blocks.

I have accredit the original effects designers by adding a suffix (in parenthesis) to each effect as follows (in alpha-order):

d=DIY2 Collection
g=Guitar Extended
s=Stamp Album Collection
v=scott vanya (me)

The included effects (basically the best I could find that lent themselves to 3 parameters) are as follows:

audioflow(v).pd
beatlooper(v).pd
bodyresonance(d).pd
chorus(s).pd
delay(3tap)(d).pd
delay(fb)(d).pd
delay(pitch)(v).pd
delay(push)(v).pd
delay(revtap)(g).pd
delay(spect)(d).pd
delay(stag)(v).pd
delay(tbr)(v).pd
delay(wavey)(v).pd
detuning(g).pd
distortion(d).pd
filter(s).pd
flanger(s).pd
hexxciter(g).pd
looper(fw-bw)(v).pd
octaver-harmonizer(p).pd
phaser(s).pd
pitchshifter(d).pd
reverb(pure)(d).pd
ringmod(g).pd
shaper(d).pd
stepvibrato(g).pd
streamStretch(v)-help.pd
streamStretch(v).pd
tremolo(d).pd
vcf(d).pd
vibrato(d).pd
vibrato(step)(g).pd
wah-auto(v).pd
wavedistort(d).pd

Note: there are too many effects to go into detail about what each parameter does. So I leave that for you to either figure out/discover on your own or post here your question and I will answer it as time/energy/etc allow.

Peace and Loving Music Through us all.

Sincerely,
Scott

@whale-av and here is the score...(Piano ready.iannix ) all in 3d and ready to go! there are 30 curves which are meant for 60 parameters... that´s as far as i can go writing wise...
Each curve will carry 2 parameters... so like i said if the beginning of the parameter list is this:
1 pitch
2 volume
3 reverb
4 chorus
5 distortion
6 wah...
The starting curve (3), will have pitch on Y dimension and volume on Z dimension.
Curve (4) will have reverb on Y dimension and chorus on Z dimension, Curve (5) will have distortion on Y dimension and wah on Z dimension... etc, you make the decision of the order of the parameter list, I would like for it to start with these 3,.,, pitch, volume, reverb..., it would be insane if we reached 60 parameters, thats as much as i could handle. of course, all these parameters would be for one voice only, and Id like to go further than one voice sometime in the future, sometimes Id use less parameters, maybe 35, or just 4, and on the next voice all 60 etc etc, the combinations are endless!