Howdy,

I seem to be missing the help file for this filter.

Does anyone know off-hand what the inlets for this filter do?

Otherwise, can anyone recommend a simple, 2nd or 1st order IIR filter, with non-signal inlets for all parameters?

thanks in advance

figured it out by trial and error.

On another note, does anyone have a good technique for monophonic legato?

I've been racking my brain over this for a while now and I'm getting a bit frustrated.

I'm trying to achieve a system that outputs a single pitch, a note off message when the current pitch receives a note off message, and a note on message that only triggers immediately following a note off message.

Does that make sense? its a hard concept to explain without a demonstration with a keyboard.

I'm not quite sure I understand, but I've so far only been able to get good legato sounds by using some form of polyphony, that way there is no conflict between one note and the next.

surely monophonic legato is as simple as ...

when new note is pressed, send note-off for last note, followed immediately by note-on for new note

nothing major. Or am I missing something?

One trick I use sometimes is to send note-ons through [poly 1 1]. With voice stealing on and one-note polyphony, it will always send a note-off for the last note immediately when it gets a note-on.

Or are you actually talking about not retriggering envelopes when a new note-on is received before a note-off?

Right. I've been fooling around with poly 1 1, and I'd like to have a trigger input that doesn't trigger when a new note on is received before a note off.

So far I've gotten moses to detect the relevant note of messages, but the single legato retrigger is eluding me.

I think the biggest part of my problem is I can't see the order that the poly object outputs its data in.

[poly] will actually get in your way here, probably, because it will generate note-offs that you don't want. I think you'll want to store the value of the most recent note-on, then compare incoming note-offs to it. If it matches, send your envelopes in release mode and allow the next note-on to retrigger. If it doesn't match, ignore it.

Right, that's the concept I've been working with, actually, haha. I'm gonna take a fresh look at it in a little while, I'm busy this week. When I figure something out, I'll be sure to update everyone.

Actually, thinking this over again, one of the problems I'd like to solve is being able to hold multiple notes and return to the most recent notes after notes are released.

My first thought is to have an array, the size of which is equal to the number of practical midi note values.

When a note comes in, it's place in the array would be replaced with a number derived from a counter, which would increase with each note on.
This way the sequence of note-ons would be stored in the array.
A note off message would reset the array value to zero

the counter would reset when all notes were off.

This would need to scan the entire array in order to find the most recent note on every legato note off.

I considered a setup where note numbers would be stored in an array starting at zero index, and increasing with each fresh note, but I feel that this would require some dynamic reentry if notes were released out of order, and that is slightly intimidating.

Before I dive into this, does anyone see any immediate problems with this approach?