What you do in your filter abstractions is rebuild a [biquad~] object with czero~ and cpole~ objects but now with signal inputs, or am I wrong? Your filters are 2nd order and according to the help patch the original vanilla object [biquad~] is also second order.
Is is so simple to cascade two filters to create a fourth order one from two second order biquad~ objects? (I thought filter design was more complex...) So this would be a correct 4th order highpass filter with 20Hz cutoff frequency:

[biquad~ 1.99293 -0.992979 0.996477 -1.99295 0.996477]
|
[biquad~ 1.99293 -0.992979 0.996477 -1.99295 0.996477]
|

@Moothart In the above example the array would only contain 2 5 6 7 10, so it would work as expected as long as the number are arranged sequentially from lowest to greatest, but [array] is not so good for this since it is a fixed size, [list store] is the better option here since it resizes itself to the list you give it.

This little block of code built around the [list store] is called a list drip, this variant being the slow variety, every time it receives a bang it drips the next element of the list. The list drip is a very common and useful paradigm in pd, good one to learn and really understand since there are countless variations you can patch up for various needs. Here I am using a [s value] for the output which sets the right inlet of the [>=] and makes it easy to get the current value anywhere else in the patch through [r value] or [v value], each having their advantages and disadvantages. I also added a [s bang] which bangs after each time the value changes, which also can be useful. That [change] I added in after the [>=] is quite important and an oversight in my previous example.

One thing to be aware of when using [v ], especially when you are also using [s ] to set that [v ], creation order can bite you.

Pd sends the new value to the [r ]s and [v ]s in the order they were created and [r ]s often execute more code, if there is a [v ] in that branch of code the [r ] executes and that [v ] was created after the [r ], the [v ] will have the old value. Generally it is fairly easy to find these bugs once you understand how creation order affects [r ] and [v ], but it can be very difficult to sort out in large complex patches. The above patch also demonstrates the importance of using [trigger], it is generally wise to just use [trigger] anytime you need to connect more than one object to a single outlet, beyond being more reliable it also tends to make patches more readable and neater even in those situations where order does not matter and you can get away without using a trigger.

@jameslo said:

@ddw_music If Pd's topological sort algorithm were smart enough to know when a change inside an abstraction did not change the sort outside the abstraction, then it would be an easy lift for it to detect that feedback to some abstraction (e.g. one with an [inlet~], an [outlet~], and no connections) does not produce a cycle. But the last I checked, that was not the case, so I would bet that when anything changes, the whole directed graph is resorted.

I guess the issue, then, is, if all the tilde objects get lifted into one flat list, then a change inside a subcanvas could get inserted in the midst of objects outside the canvas. In that case, it probably is necessary to walk the entire tree.

In the video, he starts off the sorting section by saying that canvases tell the DSP layer what has changed locally within the canvas, but then discusses the sorting flow when DSP gets turned on (which obviously has to start at the topmost canvas).

And then in g_canvas.c there are comments like

        /* create a new "DSP graph" object to use in sorting this canvas.
        If we aren't toplevel, there are already other dspcontexts around. */

so the data structure does seem to be split up by canvases.

It's not a crucial point -- just that, I'm expending a paper and wanted to contrast SC's per-SynthDef graph sorting vs Pd's seemingly global sorting. I'd rather not make a false claim.

Mailing list, I guess.

hjh

@jamcultur The command line flags set the devices to use when Pd is started. They can be used in Pd preferences to fix the devices without opening the midi dialog and saving the setup after starting Pd.
Not so useful in Pd preferences as they will always be the same, they are very useful if starting Pd from a batch file in windows, as you can have different setups for different hardware setups....... e.g. in the studio or out at a venue.
I am not sure how they could be used in Linux... maybe starting Pd from a shell script.

However, the order of devices almost definitely depends on the order in which they were plugged in before starting Pd so it needs some rigour to use -midioutdev. Using -midiaddindev and -midiaddoutdev rather than -midiindev and -midioutdev might solve that... ? I don't know the syntax..... but maybe a list of the devices by name and in the correct order after the flag...?
That could be problematic because of spaces in the device names.... see below.

I see elsewhere that you have a problem having to re-start Pd when plugging in more midi devices.
I wonder whether a request could be made to the Pd-list.
In Pd-extended devices were hot-connected when plugged in, but that is no longer the case in Vanilla. The midi-dialog.tcl file is completely different in the two versions and depends on other .tcl files and probably also on the Pd binary, so midi-dialog.tcl cannot be simply replaced.
There is also a fixed limit of 9 midi devices. I think windows has a limit of 10, and the registry needs to be edited by removing an old entry before adding a new one.

There are ways to set devices from within a patch using [midisettings]........ see set_midi-order.pd.... midisettings.zip
The idea is to reset the order of devices to what is required, by sending a list to Pd (a midi-dialog list).
It will need some work, using [midisettings] (part of the mediasettings external) as the names returned by the [listdevices( message are symbols with spaces inside. Since some version of vanilla the spaces can be escaped so the complete symbol can be used in the route object.... https://forum.pdpatchrepo.info/topic/13506/list-comparison/2
Otherwise, for older vanilla you will need [concat] which is in the thread.

So get the midi device names with their order numbers, and then re-order the numbers by device name according to what you require, and then send the re-ordered numbers back to Pd in a [midi-dialog( message.
When you implement that it will no longer matter in what order you plug the devices or in what order they appear in the midi settings menu when you start Pd.

Here is a quick re-write of set_midi-order.pd escaping spaces with a backslash for midi devices on my system....... set_midi-order.pd

The same can be achieved for audio devices using the [audio-dialog( message and [audiosettings].
David.

It's just an Multi-Layer Perceptron (MLP) - a dense feed-forward neural network. Each neuron sends its output to all neurons in the next layer. Each neuron in the next layer multiplies its of its inputs by a weight. The weighted inputs are summed and added to a bias value, then passed through the activation function of the layer (e.g. a sigmoid function to ensure everything remains between 0 and 1 and don't go to +/- infinity) and passed to all the neurons in the layer after that.
It's all in the C code. If you want to learn more about this though (in case you don't know), I recommend the "Neural Networks from Scratch in Python" book, which is where I initially translated Python code to C to create this object.

Thanks you both for your answers!

@whale-av said:

A round-robin approach would work, but you would have to always play 3 note chords and if a note was missed the order of the instruments would be shifted.

Yeah. I was afraid of something like that... Would this be something like {poly]?
I think what I want is pretty difficult to solve. I just want to be able to play a couple of monophonic instruments as an ensamble that plays the legato nicely without interfering a voice with each other.

For example... let's say I wanted to play 2 different monophonic legato instruments. Legato implies the pressing of two keys... two keys per voice. Those keys per voice are not even played together, because timings of the music. And the two voices play together or not depending of the playing style (that is, 2 voices have the same rhythm or are rhythmically independent of each other).

Just thinking out loud to see if I'm getting this right:

If you play just two note chords (same rhythm), that means 4 notes need to be played for legato to be produced, right? 2 notes per voice. If you want the voices to be orderer from lower to higher without crossings, the sequence would be:

• you would first have to order the inicial 2 notes, with the delay time to play/order that you pointed out. That gives you ordered list A.
• you would then have to play and order the 2 other notes, with delay time to play/process. That gives you ordered list B.
• with that, you would have to make so as to the lowest note from list B midi-chokes the lowest one from list A. Same with higher note.
• A little time after (as 2 notes that want to play legato must superpose), you would have to send a velocity 0 message to the notes from list A.

I can't think of a way of doing pretty much all of this... and this is just the simplest (same rhythm) case.

@lacuna said:

Indeed, stairs require lowered anti-aliasing filtering at the output.

There used to be CD players boasting of "8x (or 16x) oversampling" DACs.

They would do exactly what you're seeing here: 1. Zero-order hold the 44.1 kHz samples up to 352.8 kHz or 705.6 kHz. 2. Then, the final filter could be a gentle rolloff at a much lower order, rather than a very tight, high-order 20k - 22.5k filter.

But does always any DAC need filtering, even for sines below Nyquist??

If there's a zero-order hold, then yes, you do need to filter away the sharp corners. The added samples extend the frequency range above the original Nyquist -- but the zero-order hold does not accurately reflect the original signal. The sharp corners introduce high frequency energy that couldn't possibly exist at the original sample rate. It is necessary to remove those.

Reconstructing the signal from the samples could be done in a way other than upsampling and filtering. Sinc interpolation convolves the samples against a band limited impulse (band limited impulse = (sin x) / x except y = 1 when x = 0), and this can reconstruct the original signal at any time resolution, without filtering. But it's expensive, compared to upsample-and-filter.

hjh

@lacuna Just because anyone else has replied yet ...

I don't really understand the code of IEMlib's [filter~] but I'm pretty sure that it is indeed a biquad filter, that is: if the filter (defined by the first argument) is second order. First order filters use a similar but cheaper algorithm. Higher order filters are implemented as a cascade of first and second order sections depending on whether the filter order is even or uneven.

To get the biquad coefficients right, it's important to notice the differences in implementation. (There has been confusion in the past because Max and Pd use different implementations.) Both Pd's [biquad~] and IEMlib's [filter~] seem to use Direct-Form II, but I'm not sure about that.

This is because the execution-order is not set with [trigger].
If not defined, you can not see, which [tabread] gets the float first. (In this case the order is in the order of patching, which is bad, as we don't want to care about order of patching and we can not see it.) And if the leftmost [tabread], the one going into [pack]'s hot inlet, gets it before the others, [pack] outputs before it packs the other floats.

Put a [t f f f] or [t f f] after [mod 4], where the leftmost outlet goes to [tabread pitch] and the others to the other tabreads.

Doing so, [pack] gets data on its cold inlets first and hot inlet last.

See Pd Vanilla's documentation 2.control.examples > 03.connections
and [trigger] helpfile.

And 08.depthfirst
Pd's order of operation is deterministic.

Hot/cold inlets, right to left order, [trigger] and order of operation are the biggest step in learning Pd imo. So you are lucky this happened now )

hi, i've got this:

the purpose of which is to use multiple ways of switching between "top of the canvas" and "bottom of the canvas". I think here's a complete list

• a midicontroller (two midi messages) (Loupedeck Live device) (the button-presses on the device sends Midi messages)
• the pageup/pagedown buttons on the keyboard, if available
• shift-° to switch between the top and the bottom of the screen
• Karabiner (macOS) configured mouse buttons to send the very same message
• two red buttons (aligned so that whether in top canvas area or bottom canvas area, the button stays in the same place

..but i'd really prefer to not have this large amount of objects on the main script canvas, taking up space, since space is at a real premium for me. so i'm wondering how i could have this inside an abstraction and still get the same results on the main canvas. any ideas?

if it helps, here's my current main script view:

"Page up" :

"Page down"

so i'm really trying to reduce the amount of extra objects i have on my screen.

if you have any other suggestions on how to reduce the amount of "non-clickable objects" on screen, i'm open for anything.