Question about muliple arrays in one graph
I decided to redesign the thing, taking a different approach. Rather than try to display two arrays in the same graph, I defined one array (named "$1-array"), the only one which actually gets displayed, using the Put menu. Then I defined two other arrays (named "$1-velocity" and "$1-duration") using [array define], and a horizontal radio button to allow the user to select which of the two arrays to display. When the user clicks on one of the radio button selections, it saves the current contents of $1-array and then copies the contents of the selected array into $1-array.
It works the first time I open the patch, but when I go to close it, PD asks me if I want to save my changes (even though I didn't make any changes, except to the data in the arrays. I don't have "Save contents" checked either. If I say "No", I can open the patch again and it still works. But if I say "Yes", it replaces the original name of the displayed array ("$1-array") with the actual number (for example, "1150-array", as in the screen print below) inside the patch. I'm not sure why it's doing this, or if it's expected behaviour. It doesn't over-write the names of the other two arrays ($1-velocity and $1-duration) inside the patch, though. Any ideas?
The whole thing is getting a little complicated, so I've uploaded the parent patch ("test-array-abs.pd") and the abstraction containing the arrays ("array-abs.pd"). This is the line in "array-abs.pd" that gets changed if I say "Yes". Of course, I could try to remember never to say "Yes", but that's a bit much to ask of the user, I think. And it's kind of annoying to have to answer in the first place.
Before:
#X array \$1-array 32 float 2;
After:
#X array 1161-array 32 float 2;
Would Hanning (0r similar) window via tabread4~ be better than vline for ramping volume on a sampler?
@Tombot7 It works like a traditional attack/release envelope. The gate inlet controls the on/off stages with 1 for on and 0 for off. The following two inlets set attack and release time.
The [cos~] object when receiving a straight line going from 0.5 to 1 produces half a sine wave going from -1 to 1 so it's output is scaled to be between 0 and 1.
The release stage uses some simple math to mimic the exponential decay of an RC filter. If you want hanning fades on the release part as well, the patch could be simplified drastically:
AttackRelease2.pd
AttackRelease.pd (fixed mentioned mistake)
Here is what their outputs look like:
Colored things - and pixels
Data structures always. The first, the blue one, is the result of a stack overflow..
How to express speedlim in messages?
@ddw_music here's a version I recently made for an organelle project
float-speedlim.zip
edit: I noticed that cyclone's [speedlim]
works for any message (not just floats like iemlib's [speedlim]
) so here's a modified version to do that:
any-speedlim.zip
(if a message comes in while a delay/"pending" state is happening, set a flag and store what was received in the [list]
, and the flag in a [f ]
. After the delay/"pending" state, if the flag is set then output the contents of the [list]
, and restart the delay/"pending" state.
If in the "idle" state the incoming message passes directly through the lower [spigot]
and starts a delay/"pending" state. The lower spigot is blocked during the "pending" state, but opens between "pending" states if a message was received during the prior one, before starting a new "pending" state.)
Sigmoid functions
@bocanegra Fun, I didn't know there was a name for that. Cyclone has tanh~ and overdrive~ in case you weren't aware.
I made something similar 5 years ago when I was experimenting with wavefolding. It's sort of like fractional recursion of the second half of cosine, if that makes any sense
deformPhasor~.pd
deformPhasor~ show.pd
Here's another one based on [log~]: logShaper~.pd
Dynamically patched vslider with local send symbol
@oid This is a problem from my 2nd ever dynamic patch, so I wouldn't try to read deep meaning into my questions . Like my first dynamic patch, it's just a patch that generates the repetitive, static parts of other patches--a way to reduce the tedium of having to edit multiple send/receive names by hand, that's all. I'm expecting to have to cut and paste from this helper patch into the patch I'm really trying to write, so the value of $0 in the generating patch is irrelevant. Is that reasonable? In a patch that needed its UI to be dynamically generated, your way would make total sense, but I'm def not there yet. Also, regarding your other topic, I think the message that dynamically generates a vslider can itself be static, so I'm not sure that add2 technique is applicable.
@ingox OK, now I'm getting the same results as you, which is odd because the patch I've presented is just a small example from a larger patch that was giving me trouble. After discovering the $\$0
syntax I applied it to that larger patch, saw that it too was working, and then posted this topic. But now my larger patch is broken, which makes me believe that the system is behaving differently since running your patches (and that I wasn't previously hallucinating). But that can't be true, right?
So here's another small patch to demonstrate how my larger patch is (now) broken: dynamicPatchVerticalSlider2.pd
See how \$0
is just generating a 0
in the send symbol? When I save and reload it to test the fader (which doesn't work), the backslash gets dropped from the creation message!
So next I try falling back to the syntax I got working earlier, and the generated vslider send symbol looks good
and on reloading it I can confirm that it is good, but now I can't use my generating patch because $1 is backslash escaped!
banging [switch~] performs audio computations offline!
According to block~ help, if you bang [switch~] it runs one block of DSP computations, which is useful for performing computations that are more easily expressed as audio processing. Something I read (which I can't find now) left me with the impression that it runs faster than normal audio computations, i.e. as if it were in control domain. Here are some tests that confirm it, I think: switch~ bang how fast.pd
The key to this test is that all of the bangs sequenced by [t b b b b] run in the same gap between audio block computations. When [switch~] is banged, [osc~] fills array1, but you can see that element 63 of array1 changes after [switch~] is banged. Furthermore, no logical time has elapsed. So it appears that one block of audio processing has occurred between normal audio blocks. [bang~] outputs when that accelerated audio block processing is complete.
This next test takes things further and bangs [switch~] 10 times at control rate. Still, no logical time elapses, and [bang~] only outputs when all 10 bangs of [switch~] are complete. [rzero_rev~ 0] is just an arcane way of delaying by one sample, so this patch rotates the contents of array1 10 samples to the right. switch~ bang how fast2.pd
(There are better ways to rotate a table than this, but I just needed something to test with. Plus I never pass up a chance to use [rzero_rev~ 0] )
Finally, I've seen some code that sends a 1 to [switch~] and then sends 0 after one block of processing. In this test you can see that one block of audio is processed in one block of logical time, i.e. the normal way. switch~ bang how fast3.pd
But that second test suggests how you could embed arbitrary offline audio processing in a patch that's not being run with Pd's -batch flag or fast-forwarded with the fast-forward message introduced in Pd 0.51-1. Maybe it's an answer to two questions I've seen posted here: Offline analysis on a song and Insant pitch shift. Here's a patch that writes 20s of 440 Hz to a file as fast as possible (adapted from @solipp's patch for the first topic). You just compute how many blocks you need and bang away. write440File.zip
Here's another that computes the real FFT of an audio file as fast as possible: loadFFT.zip
But as with any control rate processing, if you try to do too much this way, Pd will fall behind in normal audio processing and stutter (e.g. listen to the output while running that last patch on a >1 minute file). So no free lunch, just a little subsidy.
s~/r~ throw~/catch~ latency and object creation order
For a topic on matrix mixers by @lacuna I created a patch with audio paths that included a s~/r~ hop as well as a throw~/catch~ hop, fully expecting each hop to contribute a 1 block delay. To my surprise, there was no delay. It reminded me of another topic where @seb-harmonik.ar had investigated how object creation order affects the tilde object sort order, which in turn determines whether there is a 1 block delay or not. Object creation order even appears to affect the minimum delay you can get with a delay line. So I decided to do a deep dive into a small example to try to understand it.
Here's my test patch: s~r~NoLatency.pd
The s~/r~ hop produces either a 64 sample delay, or none at all, depending on the order that the objects are created. Here's an example that combines both: s~r~DifferingLatencies.pd
That's pretty kooky! On the one hand, it's probably good practice to avoid invisible properties like object creation order to get a particular delay, just as one should avoid using control connection creation order to get a particular execution order and use triggers instead. On the other hand, if you're not considering object creation order, you can't know what delay you will get without measuring it because there's no explicit sort order control. Well...technically there is one and it's described in G05.execution.order, but it defeats the purpose of having a non-local signal connection because it requires a local signal connection. Freeze dried water: just add water.
To reduce the number of cases I had to test, I grouped the objects into 4 subsets and permuted their creation orders:
The order labeled in the diagram has no latency and is one that I just stumbled on, but I wanted to know what part of it is significant, so I tested all 24 permuations. (Methodology note: you can see the object creation order if you open the .pd file in a text editor. The lines that begin with "#X obj" list the objects in the order they were created.)
It appears that any time the phasor group is created before the r~, there is latency. Nothing else matters. Why would that be? To test if it's the whole audio chain feeding s~ that has to be created before, or only certain objects in that group, I took the first permutation with latency and cut/pasted [phasor~ 1] and [*~ 44100] in turn to push the object's creation order to the end. Only pushing [phasor~ 1] creation to the end made the delay go away, so maybe it's because that object is the head of the audio chain?
I also tested a few of these permutations using throw~/catch~ and got the same results. And I looked to see if connection creation order mattered but I couldn't find one that did and gave up after a while because there were too many cases to test.
So here's what I think is going on. Both [r~ next] and [phasor~ 1] are the heads of their respective locally connected audio chains which join at [-~]. Pd has to decide which chain to process first, and I assume that it has to choose the [phasor~ 1] chain in order for the data buffered by [s~ next] to be immediately available to [r~ next]. But why it should choose the [phasor~ 1] chain to go first if it's head is created later seems arbitrary to me. Can anyone confirm these observations and conjectures? Is this behavior documented anywhere? Can I count on this behavior moving forward? If so, what does good coding practice look like, when we want the delay and also when we don't?
Debugging Externals With Xcode 12
For anyone interested, I was able to figure out how to do it using the original guide for earlier Xcode versions. The mistake I was making was to attach the full package of Pure Data to the debugging scheme as the executable. The correct way of doing it is to link the actual executable file as described below.
In Xcode (this is v 12.3):
- Create a new debugging scheme
- Edit the new scheme:
- In the Executable drop-down menu, select Other...
- Find the executable for pd (e.g. /Applications/Pd-0.51-3.app/Contents/Resources/bin/pd)
The settings for the scheme should look like this (notice the setting for Launch - Automatically)
- Build and run the external. This will start Pd. The actual debugging will begin when you instantiate the external object inside a patch.
In my case, I added a breakpoint inside the bang() method. Upon receiving the bang, the breakpoint is reached:
cpu problems
Hi,
I create a patch with an object that is a physical model synthesiser.
I think the patch is well made and not complex at all, but I have bigs problems with the cpu. In fact when I play the instrument the latency is too much. I have also some digital distorsion.
Could someone more expert than me get a look to my patch?
Thank you
vs.gain~-help.pd lmnts~.pd_darwin
vs.gain~.pd lmnts~-help.pd lmnts.pd mallet-lmnts.pd