Hi.

I have built a step sequencer and I would like to record polyphonic notes into it. So far I figured out how to record monophonic notes into a table. But I am bit overwhelmed on how to do that if notes are polyphonic.
Does anyone knows how that would work?

The answers in this thread are all true... clone ... data structure design ....

@impression said:

So I think the core issue I’m running into is how to read out a list in a serial way

This is called list-drip. There are many [list-drip] objects in different libraries: Both, Vanilla abstractions and compiled ones.
And in list-help is "example3 list iterator". Changing [+ 1] to [+ 2] and [get $1 1( to [get $1 2( drips the list in pairs:

(btw where "store the remaining list" comment is wrong. It should be: read the list)

Oh man, thank you so much. Looks like I should have checked the help file a bit more carefully.
I’m sorry if those are dumb questions, but it can be quite overwhelming as a beginner.
I really appreciate your help. Thank you

@impression said:

I can’t really use [clone] for my synth setup.

I'm curious, why is that? There's probably a solution. If it's the first time you're using [clone], I can see how it might be tricky to figure out, but "haven't figured it out" may not be the same as "can't use it."

I’d basically need to generate my own note on and note off messages manually.

That's probably the [makenote] object.

hjh

@ddw_music said:

I'm curious, why is that? There's probably a solution. If it's the first time you're using [clone], I can see how it might be tricky to figure out, but "haven't figured it out" may not be the same as "can't use it."

agreed
I should have probably phrase it better.
.
.
I am fairly close, but can't solve this last one issue.
Once I am reading out my list, I am iterating through each value, the issue is though, its probably not always in order, which messes up the actual notes.
I guess I would need to go through each list and combine it into another list. So basically I would need to take the next first input of each list(textNotes,textVelocity,textLength) and combine it into another list so that I have pitch, velocity and length in one list for each note, set by the index. I just don`t know how to achieve that.

I thought maybe list split could help? Always just splitting the next first one and writing it into a list for all of them? But I would need to iterate through that as well I guess

@impression What if you store your chords in the format:

note0 vel0 dur0 note1 vel1 dur1 ...

That is, don't bother with clumping all the note numbers together at all -- interleave them from the start.

Then your iterator can "get $1 3" and increment by 3 each time.

Maybe an example later when I have a bit more time.

hjh

Yea. That was my initial idea. But it seems like it comes to a similar issue.
What comes out from notein i would need to write into a text. If i play polyphonic I would get multiple notes which i would also need to iterate through at first and bring them in order if I am not mistaken🤔.
It all works if its monophonic. But polyphonic I can't sort it out.

@impression I think it's not possible to avoid the central problem, which is associating a note-off message with the prior matching note-on message. Unfortunately, this problem takes some careful thinking. It's tempting to avoid doing this careful thinking at the incoming-message stage and try to push the problem off to another part of the patch. But, I think everything is going to be easier if the note parsing is done correctly in the first place.

I think you will need one [text] just to parse the messages into chords, and then another [text] as a chord repository.

The basic flow I'm thinking of is:

• Use [poly] to assign an index to incoming note numbers. (Why? Because, when a note-off message comes in, you have to find the matching note-on record and look up the time. Then you can use that time to calculate the duration. There is no way to do this without matching note-on and note-off, and [poly] does this for you.)

• Note on: Some jiggery-pokery to rearrange the note-on data into the format "poly-index timer-value note-num velocity" and then write this list into a [text] at the row number where that index lives.

• Note off: Find the [text] entry matching index, unpack it, subtract the current time from the message's time (to get duration), pack into the desired format "note-num vel duration' and add to the current chord.

I had to make a decision about how to know when the current chord is finished. In this patch, it's when all notes have been released -- [pd notecount] gives a bang when a note-off decrements the active note count down to 0. That may or may not be right for your use case, but that part can probably be adjusted without requiring too much surgery on the rest.

In any case, in the end I get messages such as the following:

chord: 69 101 394.739 62 101 394.739 60 101 394.739 64 101 394.739 67 101 394.739 71 101 394.739
chord: 65 101 394.739 72 101 417.959 67 101 394.739 69 101 394.739
chord: 71 101 394.739 65 101 394.739 60 101 394.739 62 101 394.739 64 101 394.739 72 101 394.739
chord: 65 101 394.739 64 101 394.739 67 101 417.959 72 101 394.738 71 101 394.739

... which could be read out in groups of three for playback. (The durations and velocities are all the same because I was testing with MIDI notes from SuperCollider -- I had specified a duration of 400 ms for each note and Pd is pretty close to that. So I think that confirms the approach.)

(Note that it's a good idea to reset the [timer] at the beginning of a run -- I set up MIDI controller 37 as a trigger for that but you could do it any other way you want.)

hjh

midi-parsing.pd

Omg, never in my life would I have figured that out.
Thank you so much. Really appreciate your help.
I think I will be busy for a few days studying it properly.

@impression said:

Omg, never in my life would I have figured that out

Around 2019 or 2020, I might have said the same thing.

I'm more accustomed to working with the high-level language, SuperCollider. In this case, it's easier to write this logic in SC because, using SC arrays where pack/unpack is used in the Pd patch, you can access any element at any time, and pack a new array just by writing [item, otherItem, thirdItem, etc.]. In SC, most of the spaghetti in the orange part could be written with a single line: [list[2], SystemClock.seconds, list[1], list[0]].

The orange bit is really only reordering the input list, and adding an item for the current time. (Why did it have to be ordered with velocity first? Because that's the only way to get [route] to split note-on and note-off.) It looks massively complex, but it's really not doing anything more than that. The complexity arises because data flow out of [unpack] in a different order than they need to go into [pack] -- the [unpack]'s right outlet needs to be withheld, so that [pack]'s hot inlet at left is not triggered until all the other inlets have been populated.

There are plenty of tricks for that (e.g., the use of [f] on the orange side). It took me a few years to learn them. You can learn them too.

hjh