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.
-
Weird velocity behavior
-
@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
-
@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.
-
@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?