Bytechip Automaton - Combining Automatonism v3.0 + Bytechip equations.
@Boran-Robert said:
Here is a patch that makes a small improvement over the Bytechip music idea.
patch download :
Bytechip Automaton.zipsnapshot :
Sorry to bump this thread 4 years later, but I've made some modifications that I couldn't help but sharing due to how much enjoyment I've gotten out of this. I took the liberty to add some automatic modulations (and then a button to toggle even further modulations). This necessitated editing the VC-counter module to output a bang. Auto start (makes a neat noise if you do), and some other touches with comments. I hope you don't mind if I use this this for some a PD recording I'd like to release as a track to Bandcamp (attribution share alike)
main.pd Bytechip Automaton.zip
Edit: I noticed a clicking noise - for some reason the LFO was defaulting to a heckin saw wave even after clicking the checkbox and saving it in the gui. I went in to the save state.txt and now the LFO is modulating the crossfader WITHOUT clicking. Sorry if you loaded the clicky version, it sounds better now.
Is there a shorter way to make this logic?
Looks like the patch has many duplications. For this [clone] can make sense.
While you have to get used to how to deal with [clone], later it makes changes of the patch much quicker.
With [pdcontrol] you can read the arguments.
Here is an example, where [moses] and [expr] are fed by arguments of clone.
The right outlet of [moses] is sent to the next clone-instance.
withpdcontrol.pd
withpdcontrol-openthis.pd
EDIT
Without [list store], less memory:
wpdcontrol_woliststore.pd UPDATED, fixed two bugs, now it should work
wpdcontrol_woliststore-openthis.pd
help with polyphonic synth
I realized, after posting that, that there are two ways of thinking about the "extra parameters" going into the synth clone, which for lack of a better term I could call "global" vs "local" parameters.
Local parameters are "per-note" -- they are set at the time the note begins, and they hold their value for the duration of the note. The next note (which might overlap) could have completely different values.
Global parameters affect all notes simultaneously. This is the usual way that, for instance, filter frequency works. You twist the filter cutoff knob and all notes' cutoff changes simultaneously (even though each note could have its own filter cutoff envelope).
At minimum, pitch (note number or frequency) and velocity (on/off trigger) should be per-note. Other parameters could be global or local (and you can mix those styles).
As far as I can see, the best way is:
- All local parameters get packed into a list, along with the clone instance number (which is supplied by [poly]). The "local" list goes into the leftmost input, and only the leftmost.
- "Global" parameters add one or more inlets to the right. Note carefully in the [clone] help file that control inlets need to tag their values for specific instances. If we're using these as global parameters, then the tag should be
all
. Signal inlets are always global.
IMO it's best to be consistent about the handling of these input types, to avoid introducing bugs into your patch.
Example with filter cutoff and envelope parameters treated globally:
Example with filter cutoff and envelope parameters treated locally:
(Note: The example patches use the ELSE external library, and the global one uses cyclone.)
Hope this helps. IMO polysynth is a basic use case for any audio programming environment; if what I've posted here can't be easily figured out from the documentation, then it suggests a gap in the help. (One reason why I worked it out is that I teach a class in Pd; if the students ask "how do I make a poly synth?" then I'd better have an answer at the ready. So I tried a few ways and came up with this as a basic template that Just Works... then, just do it that way.)
hjh
creating custom kink~ , selector~ @ audio rate
I am trying to recreate the cyclone custom kink module , which distorts the phase of the phasor
This is the implementation in reaktor primary
A comparitor compares the incoming phasor sig X ( range 0-1) against variable D .
When x > d , then green field algo , when X<D blue box algo .
The output of the comparator~ ( which is square wave ) should then open route the algo's to an audio rate selector ( just like reaktor °) , but this just isn't working .
The algo's are correct , could it be that the selector module is not selecting it's input at audio rate ?
Here's the patch
customkink.pd
Result ( in reaktor °)
Equal power panning -- square roots or cosines?
Which is the "correct" way to implement equal power panning, using square roots or cosines? After doing some googling, I found posts recommending both methods. And which would be more efficient, if they're both "correct"? I've tried both and they both sound the same to me, and seem to give the same results, as far as I can tell. I compared the output from [env~] of the input signal with the summed output signals (left and right), and didn't see any difference. When panned near the middle, the RMS of the output signal is a little higher than the input signal, using either method (see screen prints below). But that may be due to the way [env~] calculates RMS, I don't know.
Here are my two implementations, [pan~] using the square root method and [pan2~] using the cosine method.
pd UI object same as in maxMSP
I did this long time ago that use on canvas to do the (clickable) gui
also the other one:
I'm trying to build filters with [pole~] [zero~],but I'm so confused with the factorization of the two-zero transfer function:
I tryed to use Cross multiplication and Conjugate roots to factor the transfer function of two-zero feed-forward filter but...I can‘t get the result like :
(1-Z1z^-1)(1-Z2z^-2) on p362.
The name of the book is Designing Audio Effect Plugins in C++
Same function can be found here but no explation about how to factor:https://ccrma.stanford.edu/~jos/filters/Two_Zero.html
PlugData: Pure Data with a JUCE GUI, as audio plugin or standalone
There have been many interesting developments recently:
Document browser for opening patches and helpfiles:
Deken support:
Control automation from PlugData, with a button to create the receive object for you:
Object argument suggestion:
Hover messages for inlets/outlets:
Where to raise deken package issues?
Is there a channel to register issues with deken packages?
I chose (unwisely, as it happens) to release an abstraction that depends on PDContainer.
In Linux, the most recent upload is from 2015, and it ships separate binaries for each object: [declare -path pdcontainer].
Then I found later that the latest Windows upload is from 2018, shipped as a library: [declare -lib PDContainer] (note also that the case of the folder name is inconsistent with the other upload, in a not useful additional source of confusion).
So, OK, I can do [declare -path pdcontainer -lib PDContainer] and accept that I will get a spurious error message in Linux.
But it would be better if these could be made consistent... but I'm not sure where to take that request. The original developer of PDContainer is Georg Holzmann; the Linux uploader is chr15m; and the Windows uploader is lucardo -- so I guess it would be pointless to approach the original developer... but then, where to go?
hjh