[PD] my first extension, FINISHED

[Frank Barknecht]

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/MonophonicKeyPolicyDiscuss

Ciao
-- 
 Frank Barknecht                 _ ______footils.org_ __goto10.org__