you did spread misinformation about it

So just correct it and move on.

When people try to reinvent what already exists... I built this for the community. Ignoring existing tools and efforts misses the spirit of open source

Both Pd and SC have a systemic problem wherein there is no good way for new users to know which extensions exist. Recent versions of Deken improve the situation somewhat for Pd, and there's a similar effort underway for SC, but "missing the spirit of open source" is quite a burden to lay on somebody who might have using the tool for just a couple of weeks or months.

So I'm out of this thread. I like a lot of the stuff in else, really, and I wish I'd known about it from the start. (Btw "when it's there in plugdata already" -- when I started using Pd in classes, there was no plugdata and there was no pd-extended, and no way to discover ELSE by chance.)

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

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

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

@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

Finally posted video from my electronic ensemble class's concert last June. Pd didn't figure into the audio side, but 2 out of 3 pieces used Gem for the graphical backdrop.

It was a fun night, hope you enjoy!

Link goes directly to the third piece; the playlist includes the other two.

hjh

Here's a short clip of an interactive installation piece (I guess more of a prototype?) that was shown last weekend.

• Audio: SuperCollider (+ VSTPlugin for the piano and guzheng)
• Graphics: Pure Data + Gem
• UI: Open Stage Control (with heavy CSS gradient abuse -- iPad batteries really don't like rendering 13-14 new gradients, 9 times per second)

Musical decisions are made by flipping bits in a 40-bit word, and mapping various segments of the bits onto sequencing parameters.

At some point, I'd like to do an explainer video, but not today.

hjh

Ahem.

lol

hjh

@jameslo said:

@whale-av My issue is (was?) that there are things that affect the DSP sort order that you can't see from the graphics alone. As far as I understand, that's different from @ddw_music's question, which is "how much of the DSP graph does Pd have to resort when there's a change"? That said, I don't understand the reason that @spacechild1 gave on the mailing list--I'd love to see an example.

Well, here's what he said: "The issue is that DSP objects can be 'connected' by other means. Take the delay objects, for example. Some of these objects need to be aware of the order of execution within the DSP graph. Others will affect other objects, e.g. automatically changing the channel count. Pd itself doesn't know what a particular ugen is doing, so the only thing it can do is rebuild the whole graph."

@whale-av Yes, I'm writing a paper, but the paper isn't about Pd graph sorting -- this is a side point -- the latency thread is interesting but would be way too much detail for basically a footnote.

hjh

Per spacechild1 on the mailing list: Yes, it does sort all dsp objects in all canvases, every time (because they may have invisible connections, like delay objects or send~ / receive~ / throw~ / catch~).

hjh