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

@dreamer said:

I don't think you understand what AI is or does

+1

yeah, you won't be able to install externals in purr data

why not use vanilla or plugdata? else has [play,file~] which supports mp3

what is the issue where it doesn't handle it nicely? I can maybe improve it on the object itself

please open an issue on my repository

read the help file...

to access weblinks you need to use the "download" message

all I need is someone that can jump into the repository and face the challenge of succeeding in building it for the raspberry pi https://github.com/porres/pd-else/

even better would be to make github actions also support pi binaries

note, however, that there are more than one possibility for binaries, 32 x 64 bits and stuff. I don;t know what makes sense in building and providing

Sorry, I am completely ignorant on all of this.

Yeah, I still need help @timothyschoen may also help me as the bottleneck seems to be ffmpeg support.

It'd be great if you could help us

yay

Hi, after a test phase with Windows errors, it seems we solved the windows compilation issues and here's the update I'm wrapping up for the PdMAXCon in a few days! I just have to ship this, but I had a new [streamin~] and [streamout~] objects for streaming and I'm leaving it out for now cause the build for windows is still failing. Hold on for that. Note that older ELSE versions are not working on Pd 0.56. This one requires 0.56-1!

My last update aimed at a PlugData update but that didn't happen yet, though there's a PlugData 0.9-2 test release, based on 0.55-2. This new ELSE update will hopefully come soon right after at PlugData 0.9.3, or maybe even a newer update. I was hoping to better coordinate releases but it's not happening

There's a lot of new stuff, but I'm mainly focusing on my MERDA modules, which I'll show at PdMAXCon. They're coming out fancy with lots of stuff and details I can't get into. There's lots of eye candy, like Implementing a new mechanism for minimizing and maximizing the GUI or opening in a new window. Added "tab" navigation for most knobs in the modules. This is just the tip of the iceberg as there's lots of work to support this, so I made several changes and updates to [knob] and [button]. The [knob] object also gained several features and it became a feature-creep monster. Now I'm also including mouse wheel scrolling, for one thing.

There's a new "Super Saw/Square" oscillator (a sum of 7 oscillators based on JP-8000) abstraction object that also became a MERDA module. I wanna highlight a new [mix~] object made for it that makes convenient mixing and panning MC connections. There's also a cool [arpeggiator] abstraction, in the next release I hope I'll have a new MERDA module with that included.

This is the main deal! There are 15 new objects, I'd like to also mention mid/side encoding and stereo widening, and another one for envelope following. Total number of objects now is 587! The tutorial now has 561 examples and an expanded subchapter about stereo imaging and improvements to envelope following.

It's up in deken, let me know if something is wrong...

There are of course many many other numerous changes and fixes. Detailed changelog in https://github.com/porres/pd-else/releases/tag/v.1.0-rc14

As of now, I started being more careful with breaking changes. I'm still allowing old patches to run, but telling people to adapt to new stuff. For instance, I had a [del~ in] and [del~ out] object now split into 2 ([del.in~]/[del.out~]) thanks to a new functionality in Pd 0.56-0, but you can still call the old [del~] object (for now). Like I've been saying, I'm just waiting for PlugData 1.0 to call this a final release as well.

Please support me on https://patreon.com/porres

#puredata #pdvanilla

cheers
Alex

else RC13 is not ready for 0.56-0

I'll release RC14 in two weeks and it'll be good for it

@porres said:

but check [else/score] and [else/score2]

@cfry did you check these?