Hallo, Atte André Jensen hat gesagt: // Atte André Jensen wrote:
Hmmm. It seems it got confused when receiving a noteon for a note that was already on (so without the acompanying noteoff inbetween), something that's quite difficult to pull off with a midi keyboard. I think it handles it a little bit smarter now. Could you please run your test again, as I'm not exactly sure if I'm just lucky here?
It doesn't do the "reset to 0" anymore, however I'm not yet sure if it is acting as it's supposed to be. At least it's not acting as the help patch explains. Quoting:
"[legato] transforms output from [notein] to legato following these simple rules: left output: the most recently pressed note. right output: 0 if no notes are pressed otherwise the velocity of the first note that was pressed."
If I press "60 60" first the output is "60 60", which is fine. If I then press "61 61" the output is "61 -" (- for no output), which is not quite what the comment says: I'd expect "61 60", so either the comment or the external is wrong. If I then press "62 62" I get "62 -", as before. But now: If I press "60 60" again, I get no output anymore although now "60" is the most recently pressed note. If I press the noteoff "60 0" I also don't get output!
Another interesting example:
In Out 60 60 60 60 61 61 61 - 60 0 - - 60 60 60 - 60 0 61 - 61 0 - 0
I can see what you're aiming for - monophony with last note hit priority and no retriggering envelopes - but your explanation doesn't seem to be consistent with that.
But anyway: It's nice to see someone working on monophonic voice policies. On my wishlist are these:
- low note priority;
- low note priority, re-trigger envelopes;
- high note priority;
- high note priority, re-trigger envelopes;
- last note hit priority;
- last note hit priority, re-trigger envelopes;
after [1].
Of course then the object name should rather be something like "monosomething" instead of "legato". ;)
One thing that IMO should accompany every Pd external is a help patch. Just make a file NAMEOFEXTERNAL-help.pd (legato-help.pd) that shows and explains what your object does, what the inlets accept and what the outlets will produce. Ideally you'd make a little example of the object in use as well. help-patches are a good way to test objects as well.
Ok, I changed your's a bit. Is that sufficient? Would one normally keep all documentation in the .pd file, or is a README.txt sometimes used?
Normally I don't bother with a README for each single object, unless something special needs to be said (like special dependencies, libraries, license etc.)
[1] http://www.symbolicsound.com/cgi-bin/bin/view/Share/MonophonicKeyPolicyDiscu...
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__