Hey folks, a little progress report since the first post.
The most visible thing: I built a small wooden enclosure, and my son printed some knob caps which we sprayed orange. 

On the software side, a few things have moved:
Pattern copying — patterns can now be copied to other pattern slots during a session.
Chord sequencer → pitch per step — I introduced a separate chord/melodic sequencer but it didn't work the way I imagined. I'm scrapping it in favour of extending the existing 64-step sequencer: each step will carry its own pitch and chord options. Simpler, more unified.
Architecture split (work in progress) — I'm in the process of separating the main patch (sequencing, saving, LFOs, modulation — everything non-audio) from the DSP patch (all the audio modules). The goal is to run them as separate processes/cores on the Pi, which should mean: saving the patch without audio dropouts, and a bit more CPU headroom. The mechanism for loading and unloading modules inside the DSP patch is dynamic patching — instantiating subpatches at runtime. The hope is that swapping modules won't cause significant dropouts, but that's still to be tested. On desktop the DSP will run as a [pd~] subprocess; on the Pi both will be launched as separate instances via the Python shell.
Cheap audio interfaces — tested a few budget Behringer USB interfaces as an alternative to the HiFiBerry. They work well and add a bit of latency, but they're functional — and they're a genuinely accessible way to add audio inputs cheaply.
More soon. Cheers!

There is a setting in my program that controls both the chord type and its level of dissonance. I had accidentally set this to slight dissonance for the previously posted song. So here's the same input melody, this time in a minor key. The next thing I'm going to do is render the same input melody with a variety of chord types instead of endless minor chords.

Here's an updated version of the patch with the correct chord voicing:

PAiA-Chord-EGGv003.pd

Also wanted to share this electronics project. Stefan Vorkoetter designed a version of the chord egg using modern ICs.

https://www.stefanv.com/electronics/chord-egg-2015-remaking-a-paia-classic.html

@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

Hello, I have a technical problem I hope someone can help with. I'm working on a simple sequence that switches between two guitar chords, A and D. Each chord strum is recorded as 4 separate samples, and I have set my patch up so that a random sample is played for each strum, to add a bit of interest and variation to the loop.

Changing chords between A and D is automated in my actual patch, but here I have simplified it so that I click the message boxes banually to try to debug my problem.

The problem is that when the message box is clicked or banged, it doesn't only send the list to be split and opened and read below, but it also plays all the files in the message immediately on click/bang.

My question is, is there a way to silently trigger the array of files in the message box so that they get sent to the list to be split, etc?

The PAiA Chord EGG creates an endless stream of majestic tones.
As soon as you turn it on, it instantly sends the listener on a trip to the underground oceans of the Europa.
The circuit was made by the American synthesizer company PAiA in 1978, and was distributed in electronics magazines for DIY builders.
Detailed schematics for it are still available online, but unfortunately one of the ICs is obsolete and difficult to obtain.

After studying the schematics and listening to recordings of it, I decided to make a version in PD.
The Chord EGG randomly selects between four chords. Importantly, each note in a chord is faded in and out by a random slope generator, which I made by filtering a sample & hold source. The complete output is then made stereo by a pair of bandpass filters, which also have a random slope controlling cutoff.

No abstractions are needed, but it can be used as an abstraction within other patches in addition to a stand alone patch.

Enjoy!

PAiA-Chord-EGGv002.pd

All credit for the original circuit design goes to PAiA, John S. Simonton, Jr. and Craig Anderson.IMG_2287.jpgchord-egg-low-res.jpgPAiA-Chord-EGGv002.pd

@ChicoVaca Yes.... but 0-39, 40-59, 60-79.... then the right outlet of [moses 80] 80+.

Anything will be possible....... but that will take some thought.
The patch I posted will take a chord and play it except that if more than one note of the chord falls into the same register you will need multiple players and [poly] to keep track of the notes....... like this with a player in place of each [print]....

I say anything is possible, but in order for Pd to know that it is a chord that has arrived at [notein] a time window would need to be set...... i.e. this note +that +that in 500ms is a chord.. because there is no such midi message as a chord... it is just a string of note on messages and then note off messages when the keys are released.
That would then allow you to make the list with the 3 notes and sort them.

But that will introduce maybe unacceptable latency.
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.

As I said... it needs some thought..... probably a lot.....
David.

@whale-av said:

@gentleclockdivider "Let's recap , a chord ( thus separate incoming midi notes perceived as a chord ) goes into pure data , I want to extract the midi note values .
UNpack -only unpacks last received note+velocity , that's why I wrote that an object that detects the time between incoming events could be the solution .
SO let's say I play a simple c min (midiin) , which has the midi note nr's 48 , 51 , 55 ....I want these these to appear in separate numboxes ."

[unpack] produces all the note numbers...... but you only see the last..... a [print] will show them.
As I said at the start of this thread, [poly] will separate them for you as it indexes the notes.
You could then use [route] to separate them but [clone] is more useful as you can clone a synth inside if you wish.
The indexes from [poly] can be used to allocate the notes to the clones, and [poly] then ensures that you have no hanging notes as the noteoff messages are allocated the same index.

As the idea of a chord is human and has no meaning in Pd, midi, or even on a keyboard, why would you need to group the notes together with a timer or a threshold.... I am just curious...
To correct bad keyboard technique...?

The method using [poly] and [route] is shown in your Pd/doc folder....... Pd/doc/7.stuff/synth/1.poly.synth.pd .... since at least 2011.
David.

I reall think we have a communication error here .
I know that a chord does not exist in pure data -midi etc...and that it's a sequential message of single notes , I have expresed that in my first post .
I am also aware that only the last of the messages is shown by the unpack module .

• quote-

As the idea of a chord is human and has no meaning in Pd, midi, or even on a keyboard, why would you need to group the notes together with a timer or a threshold.... I am just curious...
To correct bad keyboard technique...?
-unquote -
Bad keyboard technique ??
I just wanted pure data to SHOW all incoming midi notes that make up the chord , not in the console but in the structure view ., , your treshold value example did that .
Why is it so bizarre to ask for that , max msp has a dedicated object for exactly that , says enough .

@gentleclockdivider "Let's recap , a chord ( thus separate incoming midi notes perceived as a chord ) goes into pure data , I want to extract the midi note values .
UNpack -only unpacks last received note+velocity , that's why I wrote that an object that detects the time between incoming events could be the solution .
SO let's say I play a simple c min (midiin) , which has the midi note nr's 48 , 51 , 55 ....I want these these to appear in separate numboxes ."

[unpack] produces all the note numbers...... but you only see the last..... a [print] will show them.
As I said at the start of this thread, [poly] will separate them for you as it indexes the notes.
You could then use [route] to separate them but [clone] is more useful as you can clone a synth inside if you wish.
The indexes from [poly] can be used to allocate the notes to the clones, and [poly] then ensures that you have no hanging notes as the noteoff messages are allocated the same index.

As the idea of a chord is human and has no meaning in Pd, midi, or even on a keyboard, why would you need to group the notes together with a timer or a threshold.... I am just curious...
To correct bad keyboard technique...?

The method using [poly] and [route] is shown in your Pd/doc folder....... Pd/doc/7.stuff/synth/1.poly.synth.pd .... since at least 2011.
David.

@whale-av said:

@gentleclockdivider You should post your incoming message, as there is no such thing as a chord in midi.
It is likely that it is a series of note velocity pairs arriving in a fast sequence.
If so, then [poly] and [clone].
If not there will be a solution, but we cannot help without knowing the problem.
David.

Did you read my first post ?
I am aware that midi is a serial protocol and chords are just separate notes send after each other
-quote-
Since a chord is essentialy multiple messages send in serial order
-unquote-
Let's recap , a chord ( thus separate incoming midi notes perceived as a chord ) goes into pure data , I want to extract the midi note values .
UNpack -only unpacks last received note+velocity , that's why I wrote that an object that detects the time between incoming events could be the solution .
SO let's say I play a simple c min (midiin) , which has the midi note nr's 48 , 51 , 55 ....I want these these to appear in separate numboxes .