I had a closer look, but could not figure out where to set the number of
inputs and outputs with PlugData.

So @xaverius, I spoke with @timothyschoen and it seems this is an issue with Linux only. You can't configure that from within plugdata, but that's a limitation of JUCE. Nevertheless you can set it up inside JACK and it should be possible.

And yes, I was able to install and instantiate a vstplugin~ object.
Unfortunatelly, I can not use it. It's too instable and PlugData always
crashes (Ubuntu Studio 24.04, PludData 0.9.1). An advantage of
Purr-Data, it's really stable.

How can you compare the stability of vstplugin~ inside PurrData since you can't even install it over there?

I do assume that such a complex external like vstplugin~ may have issues if running on PlugData, as the target development was Vanilla, and you should actually "blame" external developers for such case of instability.

Ayway, Like you said and know, PlugData is quite actively developed and bugs are fixed quickly and you can download nightly builds with the most recent fixes and updates quite easily, but you have to report issues and collaborate at least iwth that.

@xaverius said:

I cannot operate sliders, buttons and switches properly with my fingers on my touchscreen (I don't know why, but no precise response).

have you reported a bug on github? @timothyschoen is also here to help

Seems to be more actively developed.

Definitely of all forks, it's unbeatable also in keeping up with vanilla at every update.

Offers built-in effects and instruments etc (I prefer to create such abstractions on my own).

those are actually from ELSE, my library, which can also be installed in Vanilla, so not something just from PlugData. Cool thing about PlugData is that it doesn't follow this idea to provide things (objects I mean) you can only find there.

I can only set 1 input and 1 output (no-go for me, I'm using 8 ins and 8 outs).

Well, this is definitely possible, right Tim?

@xaverius said:

For my purpose even better than PlugData.

Ok, now I'm curious on what the purpose is and why you prefer it

It's not only about being outdated, which in fact it's finally catching up, but there are several incompatibilities issues and one of them is that you can't use binaries compiled for Vanilla in it, which is one of the main downers if you ask me. I wanted that at least non GUI externals from ELSE could run there, specially now that there's an effort to bring it up to date, but as it turns out, it's not simple... and I was surprised that this was true as well. I guess you have to compile it yourself somehow against purr data or pd l2ork, but the build system is just different and you'd probably need to adapt many things... :/

@kevin.cascadia said:

Did RC13 for raspberry pi ever come together? I’m really interested in patching with the new sfont~ object for my C&G Organelle.

RC13 is not released yet, I meant RC12 in that old comment, which is the last current release.

We're gonna release an update soon in a couple of weeks, and I hope @timothyschoen helps us dealingwith the issues for building for raspberry pi. It is on my list to try and make this available for the pi and I hope there are people out there who can help me building it and testing it.

unfortunately I don't have a pi in hand with me...

@mathsound said:

happens all the time

never happens to me with software like PlugData or Vanilla or any other (super collider, etc), but thanks for the steps to allow it to open

not sure what you are asking really, but yeah, [savepanel] works just right and you can't use it to save Pd files. Help file is really straightforward! "When [savepanel] gets a "bang" a "Save As" file browser appears on the screen. You then to specify a filename, and a symbol with the full patch is sent to the outlet." What is you question?

I can;t even install pd-l2ork, macos says it can't trust it

with all that, I just keep praising how Vanilla works so well, much more stable, no big surprises and all

@mathsound said:

is actively being developed

Not really "actively" I'd say... the development pace really slowed down in the last couple of years with less releases. Pd-L2ork seems much more active. About 'multiple cord connection', Vanilla has the same and actually more "intelligent patching" options.

I check in PD Vanilla 0.55-2, and adc~ works (on my new M4 Mac),
so it's definitely a Purr Data issue (with newer Macs / OS) - maybe
as it's based on PD 0.48.

0.55 down to 0.48 is basically 7 years of development behind

So actually you did provide the solution!

yeah, I had a hunch Pd-L2ork is performing and doing better

Now I wonder why Purr Data exists alongside L2Ork, as to me they look and act the same?

well, they are similar, but they're not the same, they are independently developed and not fully compatible to each other. It happens because this is open source and people can fork and work on their own branch. This has advantages and disadvantages depending on the project. For something like Pd, where the community is relatively small, I think it's bad, as it divides the community, specially if it involves incompatibilities, which is the case with Purr/L2ork, which are not only incompatible to each other, but with Vanilla, specially that. And also quite outdated, though they are finally catching up. Seems like the last Pd-L2ork version made the jump from 0.48 to 0.55! Updating libraries like Cyclone is next in the to do list, as they have a version from 20 years ago and don't have the developments from the newer phase that is almost a decade long now.

I like to point this because I think many people don't seem to grasp the differences and caveats, and maybe they don't even mind them but it's worth noting and knowing!

Even if you finally have it synced to the latest updates in Vanilla and the external libraries they carry, there are also the incompatibilities issue that I find most problematic, as you can't run the same patches on other forks (not only Vanilla), and some external GUIs weren't ported yet and I wonder if they ever will (there aren't that many of them anyway). So full Pd-Extended compatibility is still better guaranteed with Vanilla, this is a fact.

What maybe people don't really also get is that there are things beyond Pd-Extended, and new things and new external libraries that came to be after the demise of Extended over a decade ago... with pd-l2ork/purr data you are stuck with the limited set they offer and the incompatibilities are so big that you can't even run externals made for Vanilla in them. So you're missing out on some stuff...

If you can't stand Vanilla and really like GUI enhancements you can look into PlugData, which comes with some external libraires but also allows you to install libraries in the standalone app. There's also the same issue with some GUI objects in external libraries not being ported, but there aren't that many and they do offer lots that are ported anyway.

Sorry as I know this is not the reply you wanted, but any specific reason to use Purr Data? Since you are new here I thought I'd ask as it has more caveats than the struggling support for newer macOS. o, yeah, I'd suggest you to consider other options to run your patches. If anything, maybe you're not aware (and I bet most people aren't), you can also try Pd-L2ork because it is a separate fork now, but I also had issues installing it in the latest OS and reported it.

totally forgot about [mousefilter], definitely this is what it is for... and one I didn't bother making an alternative in ELSE because I think it's easy to build that.

I looked at cyclone the other day.. and it was all ruined looking.

you mean on your installing? So you didn't manage to install it correctly?

and theyve put a new one called "wind" which is from a stalker type group probably.

"They" is not Cyclone people, just so it's clear. And the 'nilwind' fork is actually a very old version of cyclone, or a fork of a very old cyclone from Pd extended. It is something that I, as the maintainer of Cyclone, consider completely useless as it doesn't really offer any advantage. I guess the idea was to simply believe that current/newer versions of Cyclone would break things and be "experimental", which is simply not true! Also, 'nilwind' was put out several years ago and no real maintenance or development is happening on that end.

or just...

I am indeed curious, but must of all of what you are exactly trying to achieve in a real world example. I have no idea what to make of your patch.

Yeah, [line~] does start and end ramps at the boundaries of blocks. Why is that not good for you? What is your use case? What do you want to achieve in a patch? Is it all just something you wonder if it can be done or not for academic reasons?

Hi, I'm simply lost with so many messages. Can I ask someone to explain me why not just use [line~] if you want to be bound by block boundaries? That was my suggestion. I mean, what is the use case of trying to make [vline~] behave like [line~]?

And, well, we now also discovered a hidden and obscure feature of negative delay schedule times in [vline~], but they don't seem to account for any real world use case yet and I wonder if it is actually bugged...

help file of [vline~] says "Ramps may start and stop between blocks and even between audio samples (in which case the output is interpolated accordingly)." So yeah, you;re just describing something that is documented.

The [line~] object, on the other hand, is bound to block boundaries, use it instead if you want this to be true

it is important to notice that we have now two forks of Pd with the nw.js gui front: Purr Data and Pd-L2ork, and the latter seems to be more updated and more regularly and actively updated than Purr.

Both don't segment cords to the best of my knowlegde. I'm not 100% sure either, but I could bet on it.

I sometimes use 'nop' as a subpatch or abstraction just to segment connections, but it's not curved of course.

@blindingSlow said:

I've "heard a rumor" that 0.56 might come with some options to make the GUI customisation a little easier.

this is not close to happening

Check else/scope~

it has a trigger mode that you can use to always display the waveform at the same point of a period