[PD] R: emulating the behaviour of a midi keyboard: trouble with repeated notes

[Athos Bacchiocchi]

thanks all for your help!

@Claude: my aim is to emulate the behaviour of a midi keyboard played by a human. so, no possibility to overlap notes with the same pitch (instead, overlap of different notes is allowed). If the random note generator generates a new note with the same pitch of another previously generated and not yet ended, the previous note must be terminated before its "programmed" time, and then the new generated note will be started.

@Mike: the patch you suggest avoids that a new note with the same pitch of the previous one is sent to output. But i want the new note to be sent, after interrupting the old one.  Moreover, this method fails in case that between the two identical notes there appears a different one, but still the old note is not yet over when the new, identical one, is generated (but this is my fault, i spoke about repeated notes, my request was written in a misleading way).

@tim: actually, i want the generator to be polyphonic, except for the repetition of the same note, since this is what happens to a human player (and my aim is to emulate a human-like behaviour).

I finally realized that my needs can't avoid a "time based" approach, i mean that i can't simply consider previous note, i should keep control on which notes are active when a new one is generated, and this means a sort of "semaphore" approach in which there are different ways, each of them becoming busy when a note gets through it, and which is set free after the note has been terminated. Each new note will chose the first free "road", except for the case in which a note with the same pitch is already keeping another road busy. If this is the case, the new note pushes the old one from that road and takes its place.

This method leads to a main limitation, that's a number of voices limitation. In fact, if we have - for instance - 4 roads, and they happen to be all busy in a particular moment, and in that particular moment a new note is generated, this note has no road available and it's discarded. But with few considerations about the interval of generation for new notes and their possible durations we can avoid this issue. And above all, a human player has no more than 10 fingers, so keeping the number of voices limited is a even better implementation of the emulation. :)

Ok, too much words, so here it is my patch. It can handle 4 voices and for now the note duration is fixed (the "3000" pipes creation argument), but it seems to work. To set a random duration (and - why not - a random velocity) i think i will have to put some [pack] and [unpack] somewhere. And yes, it's not a very elegant solution :) (instead, tim's solution is much simpler and elegant, and i will surely use in case i need monophonic melody).

Thanks to all again, without your suggestions i would have never been able to go on :D

athos






----Messaggio originale----

Da: athos.bacchiocchi at tin.it

Data: 9-nov-2009 4.54

A: <pd-list at iem.at>

Ogg: [PD] emulating the behaviour of a midi keyboard: trouble with repeated notes



 hi,

i'm working on a little project in which some notes with random pitches and duration appear at random time intervals. Each note is packed in a "midi" format (pitch and velocity), with a note-off event (pitch and zero velocity) sent after the note duration interval.

 it can happen that a new note is generated before the previous one has been stopped.That's not a trouble, since i  can handle it with [poly], eventually set to 1 voice and with voice stealing to force a "monophonic" melody. 

The problem appears if the new note coming has the same pitch than the previous one. This is impossible for a "real" midi keyboard, in fact a key can be played again only after it has been released.
This leads to an undesired behaviour of [poly]: if there are more than 1 voice, i have the sum of different voices playing the same note, with an undesiderd increase of the volume. Even worse, when the voice is only one, the note-off message of the previous note stops the new note before its assigned time duration!

I tried to set up a strategy to avoid this, but with no results.  Any idea?

thanks,
athos
                                                                                                                                                                                                                                                                  



                                                                                                                                                                                                                                                                                                                        
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20091111/f392be8c/attachment.htm>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: midi_keyboard_emulation.pd
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20091111/f392be8c/attachment.txt>