@ddw_music said:

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.

You're using [mono] here, it has a legato feature. On its own, it can control if you want retriggering or not, you can already do it, right?

@ddw_music said:

My intention wasn't to raise shortcomings with your library

Cool, I don't think there was an intention really, but you did spread misinformation about it, that the object didn't have a legato mode and made it seem like it didn't have a portamento. It's fine, really, but then don't mind me coming here to "defend" myself or better check it out before mentioning about it.

I was more bummed out about hearing [adsr~] didn't work and how it as being dismissed as a proper object without a real follow up/bug report or something. It seems that wasn't the intention anyway, but it seemed like it.

When people try to reinvent what already exists, when it's there in plugdata already, it’s not about me wanting them to use my version or feel like my work was dismissed or something. At least not "only", but I don't even see it that was as "this is my way, use my stuff". I built this for the community. Ignoring existing tools and efforts misses the spirit of open source — collaboration, feedback, and shared improvement. I’d much rather see people engage, suggest features, or report bugs so we can make things better together... not everyone doing it on their own way, when we then have the wheel reinvented many times...

ELSE is "ours". PlugData is "ours". Pd is "ours"....

I actually "stole" many ideas from things in this forum. My [mono] object was made out of some patch I found here... I do that a lot, I see scattered things out there made by the community and try to offer a centralized set of tools that is easy to find and use.

@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.

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

@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.

@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?

@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.

@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

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:

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.