Hello everyone!
I began using plugdata a couple days ago and I'm making a simple mono synth, I have already made basically everything except for a decent adsr and velocity implementation.
At first, I tried using the else/adsr for simplicity, but it caused me some problems (i.e the attack phase didn't enter the decay and sustain phase and for some reason, if I increased the attack time while the others were at 0 or 1 ms, the sound would not stop playing even after I released the key, until the attack time was over), so I tried making my own adsr envelope using a vline, I made some knobs for the adsr and packed them together so I could send the values to a message and use $ variables in the vline in order to program the ramp.
Everything works fine, until I added velocity sensitivity, I divided the velocity values from the notein -> mono object by 127, so I got a value between 0 and 1, and I packed it along with the adsr values, and sent all of them to the vline through a message.
The adsr works as intended, BUT the velocity isn't sent out from the pack unless I press at least TWO keys at the same time, if I play one single note, the adsr values are correctly sent to the vline, but the value that comes out of the pack for the velocity remains 0 until I play another note simultaneously.
I don't understand what's the issue here and I've been stuck on this specific problem for way too long, I hope you can help me understand what I'm doing wrong.

@leonardopiuu said:

At first, I tried using the else/adsr for simplicity, but it caused me some problems (i.e the attack phase didn't enter the decay and sustain phase

As the author of ELSE and the one who built [else/adsr~] I can guarantee you that the object behaves correctly and does enter the decay and sustain phase.

I can also give you a nice hint. If something doesn't work, you can contact the author to report bugs either me as the library author/maintainer, or plugdata people.

for some reason, if I increased the attack time while the others were at 0 or 1 ms, the sound would not stop playing even after I released the key

That also sounds quite crazy and I cannot confirm. You can open a bug report with a patch that shows this behaviour to you to see if I can reproduce or see what is actually going on.

It's worth noting that plugdata has an older version of ELSE and I think what you see is a well known and documented behaviour that is explained in the help file... which also shows how to configure the object in different ways. But then, reading the help file at first should be what anyone needs to do anyhow...

So, please, do that to see if there's a bug indeed before reporting it or not (or before telling people that the object behaves weird and is bad or something)

I won't look it up right now, but if I remember correctly, I think what you need is to configure it for immediate release, which is something I changed already anyway for the newer versions (which plugdata still hasn't incorporated).

@leonardopiuu said:

I hope you can help me understand what I'm doing wrong.

you can also show us your patch so we can see what is going on. It's hard to tell merely by a written description that doesn't really show the patch

I have read the help documentation in plug data regarding the adsr, I always read the documentation. I eventually tried the immediate release and it did just that. Anyway, I haven't said that the else/adsr doesn't work, I said it gave some problems to me specifically, I'm not throwing shade at the library, I'm not blaming it as I said I was asking what I could be doing wrong, I've never talked about bugs or whatever, no need to feel personally attacked for an innocent question.
By the way, it appears that the problem is actually that notein (or any similar object, actually) doesn't register note off or velocity 0 when I release a note if I'm pressing more notes simultaneously or in quick succession like legato.
So yeah, the issue, as I said before, is on my side and it appears to be caused by the way my keyboard operates in pd, I still don't know why but whatever.

@leonardopiuu said:

I began using plugdata a couple days ago and I'm making a simple mono synth

Mono synths are not simple! lol

MIDI's way of representing keyboard activity is not exactly convenient for mono use. So, I'm going to guess that the velocity and/or ADSR behavior is the result of a logic problem before reaching the ADSR.

Especially based on this comment: "BUT the velocity isn't sent out from the pack unless I press at least TWO keys at the same time..."

It's tricky. This was my solution, in the midimonoglide.pd abstraction:

Confused? Yeah. MIDI-to-mono logic is complicated enough that it will probably take you more than a couple of days of plugdata usage to really grasp it. There's no such thing as a "simple MIDI mono synth."

So I'd suggest to use either [else/mono] -- you already have ELSE lib, so, nothing else to install -- or my abstraction (which helps with mono note glide -- but you might not need that at this point.

Then, when you have properly cleaned up and filtered MIDI data, then the ADSR "should" be the easy part.

The ELSE way -- note here that every note-on sends out a non-zero velocity, so the envelope will retrigger repeatedly. I'm not crazy about that behavior, but it might be OK for your use case (and the patch is simpler).

midi-mono-by-else.pd

The hjh way -- where it becomes possible to distinguish between sliding, non-retriggering notes and genuinely new notes. (The [noteglide] isn't strictly necessary -- but, IMO fingered portamento is the whole point of a MIDI monosynth so I'm using it.)

midi-mono-by-hjh.pd

Hope this helps -- and no worries. If you made this much progress in Pd in a couple days, to the point where you run into the not-at-all obvious subtleties of MIDI mono handling, that's pretty good.

hjh

@ddw_music
Yeah, I noticed that handling MIDI for nice mono behavior isn't as simple as I thought, I'll try using the solutions you suggested as soon as I can, thank you!
Anyway, I was already using mono, but I'm not sure what it's doing (again, I don't know if it has something to do with my keyboard or if there's something that I'm missing), but thank you!

@leonardopiuu said:

I've never talked about bugs or whatever, no need to feel personally attacked for an innocent question.

Well, glad we're sorting this out, but you mentioned you didn't have a "decent" ADSR, and how you tried [else/adsr~] and it didn't work - so maybe that is not a "decent" one? That's what it sounds like

And then it didn't sound like you were trying to ask what you were doing wrong but simply stating that it was bad and then asking help about how to do something "better" on your own... so then I took it that way I read your topic again, and this is in fact a reasonable interpretation.

@ddw_music said:

(The [noteglide] isn't strictly necessary -- but, IMO fingered portamento is the whole point of a MIDI monosynth so I'm using it.)

well, [else/mono] has a built-in portamento... and I don;t know what is wrong with it or how it works with [else/adsr~] for you...

this is a screenshot of the latest [else/mono] help file (RC14), an example with [else/adsr~], with portamento and all... doesn't it work for you?

@porres said:

well, [else/mono] has a built-in portamento... and I don;t know what is wrong with it or how it works with [else/adsr~] for you...

I'm also sensing an unnecessarily punchy tone here. I won't engage with this.

hjh

@ddw_music said:

I'm also sensing an unnecessarily punchy tone

hey, no punchy tone, no, sorry, and also, I didn't realize there were two people commenting here, so I didn't even realize I was responding to somebody else (poor eye sight + ADHD + late night fatigue), which means there's nothing personal to begin with.

As for the discussion, if my objects are not working as expected, or if you have suggestions, you can open reports and requests.

With a fresher mind, I now realize there's no way with control data to not always retrigger [adsr~], unlike when you're feeding it signals. So I can suggest for now to use [mono~] instead of [mono], which allows that kind of versatility in conjunction with [else/adsr~]. And right now I'll think of a way to also offer that with control input.

oops, I'm actually wrong, the "legato" message in [mono] is a way to control if you want to retrigger the note or not...

On the other hand, it is true that [adsr~] is always retriggering when having control input, so I think I have to do something about that. One way or another, I guess the [mono] (or [mono~]) plus [adsr~] is offering what people here want and, if not, please just give me a patch and let me know what is not working as expected or what kind of functionality you'd like to see.

cheers

@porres said:

I think I have to do something about that

nah, I'll just leave as it is, the object is already too much complicated and I don't know how to deal with it (if anyone has a suggestion, please let me know). I guess I thought that you can manage what you want from it depending on how you feed it. The idea then is that you need another object to manage voice handling, either with [mono], [voices], [sustain] - objects which fo offer ways to control retrigering.

@porres said:

As for the discussion, if my objects are not working as expected, or if you have suggestions, you can open reports and requests.

OK, sure.

FWIW, I had developed my own methodology for this some years ago. At that time, I didn't know that [else/mono] existed.

I was just sharing a way to handle this problem that worked for me. My intention wasn't to raise shortcomings with your library -- it was only, "this is how I do it."

hjh

@porres said:

nah, I'll just leave as it is, the object is already too much complicated and I don't know how to deal with it (if anyone has a suggestion, please let me know).

Maybe like this? Instead of velocity --> envelope, derive a gate by way of [change]. Then multiply the envelope by the velocity value. The volume will change if the velocity changes on a slurred note. If you don't want that, it should be possible to close the spigot when slurring to a note, and open it only when a brand-new note is being played.

hjh