Snail... a pure data patch for slow sounds
Hello there, this seemed an interesting patch, so i unzipped it on a folder and tried to open it but got an unusable display and a string of errors on console, something like this (its not all of it);
list fromsymbol
... couldn't create
list tosymbol: unknown function
list tosymbol
... couldn't create
pdcontrol
... couldn't create
else/args
... couldn't create
else/loadbanger -init
... couldn't create
clone 1 0 3 0 (canvas->outlet) connection failed
clone 1 1 8 0 (canvas->list split) connection failed
else/receiver
... couldn't create
else/receiver
... couldn't create
text search $1
... couldn't create
text set $1
... couldn't create
text search $1
... couldn't create
text get $1
... couldn't create
text size $1
... couldn't create
else/args
... couldn't create
else/loadbanger -init
... couldn't create
text delete $1
... couldn't create
text_replace.pd 31 0 6 0 (canvas->select) connection failed
text_replace.pd 31 1 34 0 (canvas->trigger) connection failed
text define $0-guithru
... couldn't create
text size
... couldn't create
text get
... couldn't create
else/loadbanger -init
... couldn't create
else/receiver
... couldn't create
else/dollsym 1
... couldn't create
else/dollsym 2
... couldn't create
text define -k $0-controls
... couldn't create
array: no method for 'set'
else/args
... couldn't create
else/break -
... couldn't create
list fromsymbol: unknown function
list fromsymbol
... couldn't create
list tosymbol: unknown function
list tosymbol
... couldn't create
pdcontrol
... couldn't create
else/args
... couldn't create
else/loadbanger -init
... couldn't create
clone 1 0 3 0 (canvas->outlet) connection failed
clone 1 1 8 0 (canvas->list split) connection failed
else/receiver
... couldn't create
else/receiver
... couldn't create
text search $1
... couldn't create
text set $1
... couldn't create
text search $1
... couldn't create
text get $1
... couldn't create
text size $1
... couldn't create
else/args
... couldn't create
else/loadbanger -init
... couldn't create
text delete $1
... couldn't create
text_replace.pd 31 0 6 0 (canvas->select) connection failed
text_replace.pd 31 1 34 0 (canvas->trigger) connection failed
text define $0-guithru
... couldn't create
text size
... couldn't create
text get
... couldn't create
else/loadbanger -init
... couldn't create
else/receiver
... couldn't create
else/dollsym 1
... couldn't create
else/dollsym 2
... couldn't create
text define -k $0-controls
... couldn't create
array: no method for 'set'
else/click
... couldn't create
else/args
... couldn't create
else/loadbanger -init
... couldn't create
q 8 0 11 0 (canvas->outlet) connection failed
q 8 1 5 0 (canvas->+~) connection failed
q 8 2 12 1 (canvas->canvas) connection failed
else/args
... couldn't create
else/break -
... couldn't create
list fromsymbol: unknown function
list fromsymbol
... couldn't create
list tosymbol: unknown function
list tosymbol
... couldn't create
pdcontrol
... couldn't create
else/args
... couldn't create
else/loadbanger -init
... couldn't create
clone 1 0 3 0 (canvas->outlet) connection failed
clone 1 1 8 0 (canvas->list split) connection failed
else/receiver
... couldn't create
else/receiver
... couldn't create
text search $1
... couldn't create
text set $1
... couldn't create
text search $1
... couldn't create
text get $1
... couldn't create
text size $1
... couldn't create
else/args
... couldn't create
else/loadbanger -init
... couldn't create
text delete $1
... couldn't create
text_replace.pd 31 0 6 0 (canvas->select) connection failed
text_replace.pd 31 1 34 0 (canvas->trigger) connection failed
text define $0-guithru
... couldn't create
text size
... couldn't create
text get
... couldn't create
else/loadbanger -init
... couldn't create
else/receiver
... couldn't create
else/dollsym 1
... couldn't create
else/dollsym 2
... couldn't create
text define -k $0-controls
... couldn't create
array: no method for 'set'
else/click
... couldn't create
text define -k $0-controls
... couldn't create
array: no method for 'set'
else/args
... couldn't create
text define -k $0-controls
... couldn't create
array: no method for 'set'
else/args
... couldn't create
else/loadbanger -init
... couldn't create
else/args
... couldn't create
else/loadbanger -init
... couldn't create
mode 14 0 3 0 (canvas->clip) connection failed
mode 14 1 4 0 (canvas->wrap) connection failed
mode 14 2 6 0 (canvas->abs) connection failed
mode 14 3 15 0 (canvas->moses) connection failed
else/args
... couldn't create
else/break -
... couldn't create
list fromsymbol: unknown function
list fromsymbol
... couldn't create
list tosymbol: unknown function
list tosymbol
... couldn't create
pdcontrol
... couldn't create
else/args
... couldn't create
else/loadbanger -init
... couldn't create
clone 1 0 3 0 (canvas->outlet) connection failed
clone 1 1 8 0 (canvas->list split) connection failed
else/receiver
... couldn't create
else/receiver
... couldn't create
text search $1
... couldn't create
text set $1
... couldn't create
text search $1
... couldn't create
text get $1
... couldn't create
text size $1
... couldn't create
else/args
... couldn't create
else/loadbanger -init
... couldn't create
text delete $1
... couldn't create
text_replace.pd 31 0 6 0 (canvas->select) connection failed
text_replace.pd 31 1 34 0 (canvas->trigger) connection failed
text define $0-guithru
... couldn't create
text size
... couldn't create
text get
... couldn't create
else/loadbanger -init
... couldn't create
else/receiver
... couldn't create
else/dollsym 1
... couldn't create
else/dollsym 2
... couldn't create
text define -k $0-controls
... couldn't create
array: no method for 'set'
else/click
... couldn't create
else/break -
... couldn't create
list fromsymbol: unknown function
list fromsymbol
... couldn't create
list tosymbol: unknown function
list tosymbol
... couldn't create
pdcontrol
... couldn't create
else/args
... couldn't create
else/loadbanger -init
... couldn't create
clone 1 0 3 0 (canvas->outlet) connection failed
clone 1 1 8 0 (canvas->list split) connection failed
else/receiver
... couldn't create
else/receiver
... couldn't create
text search $1
... couldn't create
text set $1
... couldn't create
text search $1
... couldn't create
text get $1
... couldn't create
text size $1
... couldn't create
else/args
... couldn't create
else/loadbanger -init
... couldn't create
text delete $1
... couldn't create
text_replace.pd 31 0 6 0 (canvas->select) connection failed
text_replace.pd 31 1 34 0 (canvas->trigger) connection failed
text define $0-guithru
... couldn't create
text size
... couldn't create
text get
... couldn't create
else/loadbanger -init
... couldn't create
else/receiver
... couldn't create
else/dollsym 1
... couldn't create
else/dollsym 2
... couldn't create
count.pd 15 0 8 0 (canvas->+) connection failed
count.pd 15 1 14 0 (canvas->-) connection failed
else/args
... couldn't create
else/loadbanger -init
... couldn't create
display 60 0 29 0 (canvas->message) connection failed
display 60 1 31 0 (canvas->select) connection failed
display 60 2 32 0 (canvas->message) connection failed
display 60 3 31 0 (canvas->select) connection failed
Any ideas ? cheers
"Send" & "Receive" to Child PD
Hi,
first of all, i am Stef from Germany, a "once in a while" PD User since a few years. My currently used PD-Version is 0.51 running on Ubuntu 20.04.
My question is:
I have a pd-Module, which has several "Receive" inputs inside with the same Name.
I would like to use several copies of the same module with the goal to control them all independently "wireless". To do this, i would need in fact a parent PD, which has a command/Value inlet , attach it to a "Send" object wiith the, which communicates with the underlying "cloned" pd Module.
Of course this would not work, because currently every other module with the same "receive" Object and the same name in the global PD sheet would react to the command/value being send. What i would need is a "Send"-Object which only does cummunicate with a child PD Object and does not send value changes -outside- the parent PD Object, like a "Container".
Like so:
Main PD Object=>Message -only- to Child PD=>Message -only- to Child PD and so on. The Message inside a parent Patch "Container" going to a child PD should not affect any other Receive object -outside- this container.
This would save me in fact a lot of time renaming the "Receive" Objects of each individual Child PD Patch.
The only thing that has to be done, would be to have a Parent PD Patch with some inlets that connects to a send object with the same static name that the -next- underling child PD would accept - in order to prevent renaming each individual "Receive" Inlet of the last Child PD Patch.
Is this possible in any way?
Another question that i would have - is it possible to clone PD Patches in such a way, so that any change in a PD Patch could affect every other PD patch when they use the same name?
Like so: Having 2 PD Patches on the main sheet with the same functionality and the same name=> any change on PD Patch number one (adding/removing objects, wiring etc) also affects/changes the contents of PD Patch Number 2,
Kind regards
Stef
Routing different signals to clone instances
@whale-av I got it! Thank you very much! It worked very good, but I get these warning messages:
warning: 0-fm: multiply defined
warning: 1-fm: multiply defined
warning: 2-fm: multiply defined
warning: 3-fm: multiply defined
warning: 0-fm: multiply defined
warning: 1-fm: multiply defined
warning: 2-fm: multiply defined
warning: 3-fm: multiply defined
Is that something I should worry about?
@lacuna it seems to work fine without the dummy i/o but I will implement it to ensure no delay is generated.
Thank you very much guys! You helped me a lot!
Question about Pure Data and decoding a Dx7 sysex patch file....
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
Does using inlet~ create latency?
@jameslo I didn't actually go through the code but just in the simple tests I did if you create the entirety of the graph with the [receive~]
(including the [receive~]
) before the graph with the [send~]
(including the [send~]
) then it appears to be in the right sort-order.
however when I deleted the [send~]
and [receive~]
afterwards I couldn't get it back in the right order when I recreated them no matter the order.. maybe something to do with [send~]
being at the bottom of a graph and [receive~]
being at the top of one or something.
might have a look through the source later and try to figure it out for real.
I would think that this is dependent on the implementation and not guaranteed to stay the same if the implementation changes significantly tho..
Ideally all [send~]
graphs would be sorted before their corresponding [receive~]
graphs..
Does using inlet~ create latency?
@jameslo i haven't tested it but it might be the case that if you make sure to create [receive~]
after [send~]
that there will be no latency, (unless the [receive~]
is in part of the graph that leads to [send~]
). You might have to create the entire graph the [recieve~]
is part of after creating the entire graph the [send~]
is part of, I'm not sure..
edit: after testing I was not able to get that to work
edit2: after further testing it seems like if I create the graph with the [receive~]
first it gets sorted last, but not if I delete the [receive~]
and recreate it afterwards
so there isn't always latency, it depends on how the dsp graph is sorted. If the [recieve~]
is sorted earlier in the graph before the [send~]
, as in the case of feedback, then there will be a block delay since [recieve~]
will process the shared buffer's samples before [send~]
has had a chance to write to the shared buffer. (so [recieve~]
will only get the samples written in the current block by [send~]
in the next block, creating a block delay.)
Shared references to stateful objects?
I'm afraid I'm not quite following you.
Let me try again.
Imagine you've got a single sequencer in the top level of a patch.
Feeding into its input, you have a global receiver [receive in]
. (For the purposes of this example it's global. This is just didactic, and we could fix that later if we wanted.)
At the bottom of your single sequencer, you are connected to a [send]
object with no argument.
Now, you are also going to build an abstraction which you can use with that same patch. It is not part of the sequencer, it's something different. Inside this abstraction you have something like this:
[inlet]
|
[list prepend $0]
|
[send in]
[receive $0-my-output]
|
[outlet]
Finally, you just have your sequencer slice off the head of the incoming message to [receive in]
, prepend it to the string "-my-output", and send it to the right inlet of the [send]
with no arguments. Finally, you trim the list selector off the rest of the message and have your sequencer handle that message as it normally would.
This will result in the sequencer sending a message only a single abstraction instance.
Thus, you have a single state machine accessible by an arbitrary number of abstractions which can advance the state by sending and receiving their own arbitrary messages to and from that single sequencer.
but it also means there's no harm in extending the system's reach.
There is harm in extending it the wrong way. For example, the "init" message of the iemguis is often a harmful feature. Imagine tracking down an insidious bug in a program like this:
|
[float]
|
[tgl]
|
[== 0]
|
vs. this:
|
[float] [preset_node]
| /
| /
| /
| /
| /
| /
[tgl]
|
[== 0]
|
If you get unexpected behavior from the first example and forget (or never knew) that there's an "init" checkbox for that [tgl], you have to do creative debugging in order to find it:
- Right-click and open the dialog to check init state, probably because you hit such an insidious bug before.
- Close Pd, run with the "-noloadbang" flag because you've learned that if that fixes the bug there is almost certainly an iemgui init or a
[loadbang]
deep in a subpatch somewhere.
But the one thing you can't do is simply read the patch! Not only can you simply read the 2nd example, the secondary loadtime data flow is immediately obvious.
I understand the desire to just say, "forward data to this object and return me the results." But depending on how it's implemented it could be a boon or a footgun. The obvious direction of pointing to "this" object using a gpointer don't work very well in a diagram-based language.
Velocity toggle or something?
@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
Dynamic receive object
Hi All,
Is there a way to dynamically define a receive object? It is possible to do this with a send object by sending a symbol to the right inlet. I would like to create an abstraction that links (send/receive) float values in a patch. The links would be defined by two symbols in a line of a text object, one to define the 'what to receive' and one to define 'where to send' it to. But i'm stuck with the 'what to receive'.
Hope this explanation is clear enough.
Have a nice friday and a great weekend!
Boris
warning: D: multiply defined
warning: D: multiply defined
warning: D: multiply defined
warning: C: multiply defined
warning: C: multiply defined
warning: B: multiply defined
warning: B: multiply defined
warning: A: multiply defined
warning: A: multiply defined
warning: D: multiply defined
warning: D: multiply defined
warning: C: multiply defined
warning: C: multiply defined
warning: B: multiply defined
warning: B: multiply defined
warning: A: multiply defined
warning: A: multiply defined
I was not troubled by this so far operating the patch of this, but still wondering what this is? Can this be resolved? Could this be causing a problem in the future?