@gentleclockdivider [poly] I think..... + [clone] for the synth.
https://forum.pdpatchrepo.info/topic/14281/playing-chords-via-midi/3
There was, and may still be, an external in the maxlib library.... [chord xx].
David.

Thanks a lot!

This is what I managed to do with [clone], it seems to be a strange solution, a toggle feedback for doing vertical chords (all the notes at the same onset). Any other proper solution?

Here is patch.

synth.cl.pd chords-clone.pd

BTW any other solutions/ideas for doing arppegios are welcome...

Hi!

Is it possible to make a polyphonic synth that receive chords as an array/list of values? Something like this MIDI patch:

I've tried it using [clone] but could not manage to send the lists to the clone object. Here is the hard coded version that I am using:

Any externals for dealing with that?

And here the patch. polyphony-chords-as-arrays.pd

Thanks a lot!

Here, I've distilled the trigger and timing logic -- should be easy to re-add sf-play2~ etc. (and substitute the real play-duration in place of "xxxxx" in the messages).

23-0217-timed-toggle.pd

Checking the 4 cases:

Played a long time, then paused a long time:

toggle-changed: 0
last play-time was: 2997.33
long last-play: 2997.33
list-store has been set to: 0 xxxxx 1
toggle-changed: 1
pause-time was: 2348
LONG-PAUSE PLAY MSG: 0 xxxxx 1 -- started from beginning, OK

Played a long time, then paused a short time:

toggle-changed: 0
last play-time was: 3250.67
long last-play: 3250.67
list-store has been set to: 0 xxxxx 1
toggle-changed: 1
pause-time was: 1092
SHORT-PAUSE PLAY MSG: 1092 0 xxxxx 1 -- even though it's a short pause, it starts from the beginning, OK

Played a short time, then paused a short time:

toggle-changed: 0
last play-time was: 1297.33
short last-play: 1297.33
list-store has been set to: symbol resume
toggle-changed: 1
pause-time was: 556
SHORT-PAUSE PLAY MSG: symbol resume -- OK

Played a short time, paused a long time:

toggle-changed: 0
last play-time was: 1553.33
short last-play: 1553.33
list-store has been set to: symbol resume -- short play time planned to resume, but...
toggle-changed: 1
pause-time was: 2125.33
LONG-PAUSE PLAY MSG: 0 xxxxx 1 -- the long pause time overrides "resume" and it starts from the beginning, OK

I'd really suggest to add sf-play2~ to this framework, rather than replacing chunks of it with over-complicated counter mechanisms which you don't need (timer measures time more efficiently).

hjh

@dkeller I am going out all day..... so no immediate response.
Let me know if I am correct about what you want..... and maybe your reply will give you some ideas.

You want a first note...... held for more than 300ms...... to trigger a chord.
Then (only then) another note to trigger another chord immediately..... presumably all future notes to do this....... or only that one future note?

[once] is useful for such operations if only one future note is required...... once.zip

Presumably you will want a reset at some point to return to the initial state...... after a delay...... or once the second chord has been triggered?
David.

@whale-av: Thank you so much!

We are that much closer!

Indeed the the stream of counting 'bangs have ceased - thank you!

But, there is now a weird behavior. As mentioned, I am seeking to trigger an accompanying chord after 300 milliseconds - a threshold for sitting on a note long enough trigger the chord. I am testing this currently with any of 4 different octaves of 'E' from my guitar through a SONUSS 2 universal pitch to midi device. In your version of the patch (again, thank you!), the accompanying chord was triggered every other strike.

So I started toying with it. I tried deleting one of the [change] objects - the one to the upper left that had a [set 0] attached to it.

Now that I deleted that [change] object, the patch now does something slightly different: It plays (again) on the second strike of an 'E' and then thereafter, as long as I keep striking that E in the same octave. If I play a lick and land on any 'E' again, or strike a different octave 'E', I need to strike the same again to make it trigger an accompanying chord - as long as I keep striking it, and hold for over 300 milliseconds, the accompanying chord will trigger. Once I move to another note (or octave of the same 'E' pitch class), I have to strike an E twice (over 300 milliseconds) to make it trigger.

I have attached the patch you sent me with the change I made back to you:

KELLER-NEURO-2.pd

All best, and thanks in advance for having another look.
D

HI All!

I am seeking a way to stop the stream of bangs that come with a [counter].

I need to trigger some chords via midi. The idea is that PD is waiting to see if I hit and stay on a particular midi pitch number over 300 milliseconds. If I do, then PD plays a chord that harmonizes with that note.

In the attached patch you can see I have started to build something that strips the note-off message so that just the midi pitch numbers can be evaluated by select objects to the right. I use that same stripnote object to so that i can measure the time between note-on and note-off messages, which I 'count' in milliseconds.

So, I have a counter triggered by [metro 1] (at 1 millisecond to count time). Below the counter, I have [> 300] working as a threshold, so that when it is tripped, I can send the waiting midi pitch number over to the right to be evaluated (selected) to then play the chord that will accompany that note. You will see that there is no line connecting from the bottom of the threshold system to the top right, where i have a [s note#] object.

Regrettably the stream of bangs from the counter are also flowing creating a cacophony. Any help would be much appreciated. I have attached my (messy) preview below

NEUROTICA SONG.pd

I am so close to improvising with this thing! Just missing something simple I am sure. Or I am very misguided in my novice PD programming.

Thank you for your expertise!
Best,
D

(First of all, I am french, so there may be grammatical mistakes)

Hello ! I'm new to this forum and a complete beginner with pure data. I'm studying sound engineering, and our professor taught us the very fondementals of Pd, and ask us to make a patch that involves music, so I tried to create an auto-composition I.A. Basically, it's just a loop where the previous chord determines the next one with probabilities, nothing too fancy. On the left of the patch, we have the creation of the sound with the fundamental, the big web on the right is the determination of the next chord, and on the top, I'm currently trying to implement a way to choose when the next chord will play on a beat, using the interface on the bottom left.

So what I was thinking to do was to "block" the loop with a very long pipe, so what was considered the next chord had to wait for the current chord to finish playing. To know when to finish playing, I wanted to have Pd check every column of the tab, and if the value is above the line, send a "flush" to the pipe, releasing the next chord and block the one that comes next.

Unfortunaly, if I connect the flush to the pipe, Pd crash, and my computer doesn't appreciate at all.

Am I missing something ? I am creating some sort of larsen when I connect the pipe ?

Thanks for the help !

It's not at all difficult to think of a case where this would break: say, a chord player where the chords may be 3, 4, 5, or 6 notes, to be played as block chords.

In that case the user would just copy-pasta a solution for max = 6 notes, probably with a sentinel value like a negative number to mean "this voice isn't used this time." Ah, I see you mentioned this already. Anyway, the limitation can be abstracted away. That is, the user sends a variable length list <= 6 to the interface, and inside the implementation [unpack] is used to distribute the list to its outlets. The implementation could simply initialize the chord to be all "-1" values, and the incoming list replaces the necessary slots.

Just to spitball-- I think the paradigm of specifying and rigorously testing the max number of "things" is an important and overlooked paradigm for Pd. E.g., if you want to handle up to 6-note polyphony, make an interface that has a slot to specify "6" as the max polyphony in there. Then in the implementation, actually compute the maximum number of things you gave it, and discard the ones you don't need at the last possible moment. (E.g., multiply the signal for that unused voice by "0" before outputting it.)

This way the user will spend all their time testing the maximum amount of time it takes the program to do its work. The user will then get a much better idea of how stable the patch is for realtime use.

If instead you optimize for average use-- say [switch~]ing off unused voices in a piece where you have 4-note polyphony for 15 minutes and 32-note polyphony for 10 seconds-- you do probably 100x fewer tests of the realtime readiness of the 10 seconds of 32-note polyphony. And that's probably the climax of the piece!

Edit: just to be clear-- if you turn on some fancy CPU-hungry filter during the 4-note polyphony and turn it off for the 32-note polyphony, the analysis and design obviously changes.

Between my dad and I, we managed to find a much easier solution for my problem as I don't think I explained it very well. I needed to know the number of red objects the patch could see and have this number trigger a specific output. 1 red dot = chord sequence 1, for example. This is what we ended up with chords.mp4