Feature requests

[timothyschoen]

If you have any ideas for features you'd like to see, drop them here!

[FlachyJoe]

Hi,

• Middle mouse button to pan view
• Let window manager draw Standalone window borders. When the window is embedded in a Qt app the title bar is shown and double-click cause it's container to overflow. WM borders are removed automatically so such issue won't occur.

[alfonso73]

1. More audio outputs and inputs. Probably 16 is enough.
2. Copy/Cut/Paste across PlugData instances
3. MIDI input for FX version (for MIDI controlled FX)
4. Audio inputs for Instrument versions (for audio controlled things like vocoders or audio modulation of oscillators etc...)
5. At least 256 automatable parameter. But i think that should be a kind of "dynamic" number
6. Save patches in the actual DAW file (so when the DAW project is open again patches are all loaded)

[timothyschoen]

@FlachyJoe I'm not sure what you mean by "pan" view, could you elaborate? Also, are you embedding PlugData in a Qt app? That's pretty cool, but also a very non-standard way to use PlugData. If you add "setUsingNativeTitleBar(true);" to line 591 of "Standalone/PlugDataWindow.h" and compile it, you should get the behaviour you want.

@alfonso73 More audio inputs and outputs, and more automation parameters will be added, I agree it would greatly improve the flexibility. Also always having audio and midi options for all plugins would be nice, should be simple to implement. I'm not sure if a dynamic number of parameters is supported by every DAW, but I read on the JUCE forum that having a few hundred parameters is not problem.

Patches are currently stored to the DAW project, but I've seen it malfunction a few times, I'll see what's going on.

The copy/paste problem is interesting, pd doesn't actually copy to clipboard but it should be easy to change that in PlugData. It would be great if pd supported copy/pasting to clipboard, it makes it easy to share parts of patches on forums and would also allow people to copy paste between different pd variations.

[timothyschoen]

Btw, if enough people prefer to have the native titlebar, I could change it. I kinda like the way it looks with the titlebar matching the theme of the app.

[alfonso73]

1. More audio outputs and inputs. Probably 16 is enough.
2. Copy/Cut/Paste across PlugData instances
3. MIDI input for FX version (for MIDI controlled FX)
4. Audio inputs for Instrument versions (for audio controlled things like vocoders or audio modulation of oscillators etc...)
5. At least 256 automatable parameter. But i think that should be a kind of "dynamic" number
6. Save patches in the actual DAW file (so when the DAW project is open again patches are all loaded)
7. Time sync with host (samplePos, ppqs, time signature, play/stop status, etc...)

[alfonso73]

8. Add FluCoMa library ( https://github.com/flucoma/flucoma-pd )

[alfonso73]

9. Make a tutorial for adding externals and external libraries to PlugData

[timothyschoen]

Nice, also maybe the pd-fftease library?

I'll make a tutorial too at some point, ideally I'd like to port deken to PlugData but that's still far away.

I'll implement all these ideas eventually, but it might take a while because I already have a pretty big todo list.

[alfonso73]

10. Add faustgen~ ( https://github.com/CICM/pd-faustgen )
11. Add pd-fttease
12. Find some sort of bandlimited (PolyBLEP and the likes) oscillator library (ELSE abstractions are very good but since they are based on oversampling if some polyphony is needed CPU requirements can get pretty high)

[alfonso73]

I'll implement all these ideas eventually, but it might take a while because I already have a pretty big todo list.

Yeah i understand very well! Here it's just a place to write some ideas for possible future implementations

[timothyschoen]

Faustgen~ looks like it should definitely be included! I am trying to only use libraries that are still maintained and updated to work with the latest pd version, I'll have to check if that's the case for all these libraries. Right now, I can't afford to maintain a bunch of pd libraries with the amount of work that PlugData still needs, though that might change in the future.

I'd also like polyblep oscillators, I actually think that saw~, tri~ and rect~ from cyclone should be bandlimited because they imitate bandlimited Max objects, not sure but I think they aren't bandlimited right now.

I'm also thinking of adding an oversampling option to PlugData at some point, so you can easily create good sounding distortion patches.

[alfonso73]

Faustgen~ looks like it should definitely be included!

this fork seems pretty well mantained https://github.com/agraef/pd-faustgen testing it in pure data and works just great

[FlachyJoe]

I'm not sure what you mean by "pan" view, could you elaborate?

Move the view up, down, left and right. As lateral sliders do but with MMB->Drag.

Also, are you embedding PlugData in a Qt app? That's pretty cool, but also a very non-standard way to use PlugData. If you add "setUsingNativeTitleBar(true);" to line 591 of "Standalone/PlugDataWindow.h" and compile it, you should get the behaviour you want.

I'm interfacing Pure-Data with a 3D CAD running a python server (communication occurs throw a websocket). I currently run PureData or Purr-Data in a independent window but it would be greater to embed a PD interface.

[FlachyJoe]

• [x] Select and Copy from console

[timothyschoen]

Almost all these features are making it into the next release!

• Select and Copy from console
• Pinch and cmd+scroll to zoom
• Middle button for panning
• 16 audio in/outs
• 512 automatable parameters
• MIDI controlled FX
• Saving patch state works again
• Fixed many, many bugs
• New inspector, new levelmeter and many more improvements.

I'll wait a little while before I add any new libraries though, I want to write descriptions and hover messages for a large number of the objects we already have first.

If anyone wants to help out:

https://github.com/timothyschoen/PlugData/blob/main/ObjectDocumentation

These messages will appear in the suggestions box, and when hovering over inlets/outlets. I think that having such a system greatly improves the educational value of PlugData. Otherwise I'll get to it myself eventually, but it's a lot of work!

[FlachyJoe]

I think ObjectDocumentation should be a per-library list so it will be easier to add an external library. Can't we automatically look in the external path ?

Also I'm not comfortable with the idea of integrating external libraries as they are quite easy to install and can duplicate already installed ones. Integrating Deken would be much more efficient.

[60-hz]

Great. There might be many way to fill objects description other than by hand...

Fo exemple some tools that generate helps and documentations here fo the wonderful ceammc library? https://github.com/uliss/pddoc

As you can see, this lib is very exhaustive and objects are well named and classified: https://ceammc.github.io/pd-help/help-en/

As I understand that adding other libraries is not the point now, but really, when caring about software learning, ceammc lib fix all the inconsistencies of all the pd strange lib and fancy objects names (what is zexy and what is doing [niagara]?). I use only this lib now with my students and the learning curve is far better ;)

[timothyschoen]

@FlachyJoe I agree, I'd love to get deken working PlugData, it's definitely the cleanest solution. It might be a lot of work to implement this though. I'll stick with ELSE and cyclone for now, and make sure your problem with loading externals is also fixed by the next release.

@60-hz You just saved me a lot of time with this! I'll definitely use this for documentation! I've found pddocs for the vanilla objects, but they are still incomplete, so it will still require a bit of work. But it's obviously better to use an existing format.

Ceammc looks very nice, a problem is that it comes with a lot of GUI objects made with tcl/tk, I'll have to write JUCE wrappers for those by hand. I might do it eventually though!

This is really a consideration in general btw, I can add support for deken, but GUI objects written for pd have to be ported manually. So it makes sense to include a few popular libraries anyways, so we can have stuff like the keyboard from ELSE.

[timothyschoen]

pddoc integration works! Some descriptions are a bit wordy and sometimes grammatically incorrect, and there are no inlet/outlet descriptions yet. Also a preview for the new inspector ;)

It actually loads the pddoc files from the documentation folder on startup, so you can very easily add pddocs for externals. I thought this might be slow but it takes almost no time at all.

I'll also want to add descriptions for ELSE and cyclone objects, @porres I read over here that you have a format with descriptions for all objects in ELSE and cyclone. Do you still maintain that list, and if so, could you share this? Even if it's incomplete it would be very useful!

[porres]

I have no idea what you mean :/

[timothyschoen]

You mentioned having some kind of template for generating help files, I was wondering if there was an easy way to extract object descriptions (and maybe inlet/outlet descriptions) from that?

[porres]

You mentioned having some kind of template for generating help files

there's a template, but it's just a design template, nothing for "generating" (as in automatic generating).

I was wondering if there was an easy way to extract object descriptions (and maybe inlet/outlet descriptions) from that?

nah, doubt it, anyway, just have a look at any help file of ELSE or cyclone and that's it

[timothyschoen]

Ah alright, I'll just go through all the help files

[porres]

we can maybe have an online "reference" like I'm planning on doing with vanilla

[porres]

then ship the html

[timothyschoen]

I'd like to include something like that as well! I'll still add support for pddocs, because it's a good format for short descriptions and hover messages.

[60-hz]

@timothyschoen I wonder if you know about the Kiwi research project from CICM and OhmForce.

It's a collaborative oriented project based on pd and max, I am sure there is plenty of good idea here... the interface made with Juce is almost flawless and very comfortable.

https://github.com/Musicoll/Kiwi http://musicoll.github.io/Kiwi/

[timothyschoen]

I found out about it recently, I agree it feels very comfortable.

I think there's definitely some things I can take from it: I like the way many of the GUI components look and feel, I think I can pretty much copy them over. The select/resize combination is also very intuitive, that might make it into the next release. I'll also replace the straight connection style with the curved one from Kiwi, because it looks great and straightens out over long distances so it doesn't get in the way. If there are any other things you think are better in Kiwi, let me know!

Other than that, the new version I'm working on is already much more comfortable to use: I've implemented most of your suggestions at this point, the inspector and console are improved, there's a presentation mode (shows the main canvas as if it were a graph!), and you can set up your own keyboard shortcuts. You can also "pin" the console or inspector to stop it from automatically switching. It'll take me a bit longer to make sure this version is completely stable because lots of things have changed.

[timothyschoen]

I copied the bang, toggle and numberbox style, looks much better now! Also copied the "straight" path style from Kiwi. I also like the comment from Kiwi more, so that's coming too.

[timothyschoen]

Turns out that porting deken is not possible, because pd externals compiled without the PDINSTANCE flag are not compatible with PlugData. I'm looking for a workaround, but I fear that it won't be possible.

[FlachyJoe]

Hi,

• does 7291f3fea0a05bc11c780e398f88eb12581149e8 allow deken use in standalone ?

• [ ] external objects should be searched without full path ie : [iemlib/init] = [init]

EDIT : this feature currently works when the object was already loaded once:

1. [init] -> unknown object
2. [iemlib/init] -> OK
3. [init] -> OK

[FlachyJoe]

• [ ] built files should be in the build tree not in the main directory.

  cd PlugData
  mkdir build && cd build
  cmake ..
  make

  executable are in PlugData/Plugins , should be in build/Plugins

[timothyschoen]

That's probably better, also I shouldn't call it Plugins because the standalone is not a plugin.

Before that I might wanna make sure the build folder isn't so filled with junk though, otherwise the Plugins folder will be hard to find.

[timothyschoen]

Deken support is coming!

[JoshuaACNewman]

@FlachyJoe I'm not sure what you mean by "pan" view, could you elaborate?

This is similar to my question. That is, scrolling vertically and horizontally at once. In this case, @FlachyJoe is proposing dragging the content of the window to move everything.

Relatedly, if the workspace resized itself dynamically to the boundaries of the patch plus a margin for new objects, the user would be able to orient to the work, not the workspace.

This is also conversely true of zooming: when I zoom, I want to see more of what's under the cursor, which is usually not in the center of the screen.

The copy/paste problem is interesting, pd doesn't actually copy to clipboard but it should be easy to change that in PlugData. It would be great if pd supported copy/pasting to clipboard, it makes it easy to share parts of patches on forums and would also allow people to copy paste between different pd variations.

Big thumbs up to this idea. Being able to paste into a forum with a renderer would be awesome.

[timothyschoen]

Copy/paste to clipboard should already work! So I can do this:

#X obj 250 121 metro 200;
#X obj 222 69 tgl 25 0 empty empty empty 17 7 0 10 #e1e1e1 #808080 #5a5a5a 0 1;
#X obj 246 176 print hey!;
#X connect 0 0 2 0;
#X connect 1 0 0 0;

And you can just paste it back into PlugData!

I think @FlachyJoe meant that holding down the middle-mouse button can be used to scroll, if you move the mouse to the edges. This should work normally, but I think there a bug with it right now, which I'll fix soon.

[FlachyJoe]

Hi, this is the named pan in CAD:

[timothyschoen]

I see, that would be useful. I thought you meant a kind of auto-scrolling when you move the mouse close to the edge. It shouldn't be hard to implement, I'll add this soon!

[timothyschoen]

https://user-images.githubusercontent.com/44585538/180661493-666d91bb-c05c-420e-975a-13c8e1cd6b3a.mov

@FlachyJoe Like this?

[JoshuaACNewman]

Yes!

Additionally, it could scroll when dragging. For instance, when I want to select a chunk of blocks and move them to the right of the current viewport.

[timothyschoen]

https://user-images.githubusercontent.com/44585538/180875978-ac827270-61d4-4f2e-9d9a-c20099451883.mov

Done!

[tmhglnd]

Hi Tim,

I thought I'll combine some of my findings here in a list since they might not be so relevant to deserve a separate issue, but maybe you'll like to have a look if you want to improve this or not.

1. If I open pd patches (previously made in l2ork) with the dark mode it is impossible to see the difference between on or off toggle. If I then replace the toggles with a new "darkmode"-toggle, safe the patch, and reopen for edit in pd-l2ork it is again impossible to see the toggle because it is all black. Maybe it is possible to not safe the colormode with the patch?

2. The trigger does not allow to trigger numbers or symbols (for example [t 2 3.14 foo] only prints 0 0 0. I know this is also the case in pd-vanilla, but would be nice to include this. For example l2ork has it included (and then the behaviour is similar to Max)

3. Is it possible to include the zexy library? I found it in the extensions window and installed it, but can't seem to be able to use the objects (I was specifically interested in time and date so tried those, also tried zexy/time, but both didn't work). Cyclone does work that way.

[porres]

if I open pd patches (previously made in l2ork)

patches made in Pd-l2ork and PurrData have problems when opening in Vanilla as well, don't think it's doable to offer support for both.

The trigger does not allow to trigger numbers or symbols (for example [t 2 3.14 foo] only prints 0 0 0. I know this is also the case in pd-vanilla, but would be nice to include this. For example l2ork has it included (and then the behaviour is similar to Max)

Yeah, they had this great idea of making purr data's trigger incompatible to Vanilla's and I don't know why PlugData should follow this non standard syntax and behaviour of Purr Data/Pd-L2ork. Again, they're incompatible, it's a battle you can't win. Maybe if PlugData chooses to be compatible to PurrData/Pd-L2ork instead of Vanilla, but I don't think that is a good call.

This is not the only incompatibility that l2ork/purr data had the great idea of introducing and, well, actually, l2ork and purr data aren't compatible to each other as well now...

For a period of time, I had included a [trigger2] object in ELSE that behaved like that, but I decided it was something stupid and deleted it. Just use trigger in the canonical way, as it will work in Vanilla, L2Ork/PurrData and PlugData.

It would be a good call if L2ork/PurrData intended to be a MAX clone instead of a Pd fork, but this doesn't make sense and it only adds noise and confusion.

Is it possible to include the zexy library? I found it in the extensions window and installed it, but can't seem to be able to use the objects (I was specifically interested in time and date so tried those, also tried zexy/time, but both didn't work). Cyclone does work that way.

I can add a date/time object into ELSE...

[timothyschoen]

Hi Timo,

The problem with colours is the users can set custom colours for objects, which makes it hard to convert between light and dark mode. Right now, the theme will decide what the initial colour is for objects you create, if you switch themes, these colours will also stay the same. Dark mode is nice, but for any patches that also need to run in Pd-Vanilla or Pd-L2ork, it'd recommend stiching to light mode.

PlugData is based on a nearly unmodified pd-vanilla base, which really helps to keep it maintainable. So I'd rather not change anything there. Also I think that pd-vanilla compatibility is a big advantage, seeing that the Pd ecosystem is already a bit fragmented.

Maintainability is also the reason why I don't want to include too many externals. Right now, both ELSE and cyclone are maintained by @porres, which saves me the trouble of maintaining externals. I'd think that adding some date/time objects to ELSE is a great idea tho!

I'm more worried about zexy not working when installed with the package manager! Are there any error messages in the console?

EDIT: I can actually reproduce zexy not working. I'll see what's going on there.

[tmhglnd]

The problem with colours is the users can set custom colours for objects, which makes it hard to convert between light and dark mode. Right now, the theme will decide what the initial colour is for objects you create, if you switch themes, these colours will also stay the same.

Yeah that is something i noticed too, and I already thought it would be difficult to be able to keep switching between modes if users can also already change the color. No worries of course! Sticking to the light theme is definitely doable. Something else that you could think of is to not even make a dark version of those UI objects, the light version also works also quite nicely on the dark themed background imo.

Yeah, they had this great idea of making purr data's trigger incompatible to Vanilla's and I don't know why PlugData should follow this non standard syntax and behaviour of Purr Data/Pd-L2ork.

I come from many years of using Max, so using trigger this way is in all of my patches and my workflow. I agree/understand that for many other Pd users the pd-vanilla base is much more desirable.

Also I think that pd-vanilla compatibility is a big advantage, seeing that the Pd ecosystem is already a bit fragmented.

Yes, makes perfect sense!

I'm more worried about zexy not working when installed with the package manager! Are there any error messages in the console?

First searching for the library was also a bit strange, typing in zexy didn't give any results, but for some reason when I just typed the letter l it shows up. After downloading and restarting plugData the only error that i'm getting when typing [time] is ... couldn't create, same for [zexy/time]

[timothyschoen]

Are you using the last release version or a download from the "Actions" tab (or building from source)? I recently improved the package manager, the problem with packages not showing up should be fixed with recent updates.

But even then, zexy still won't work :(

[tmhglnd]

I currently have the latest release installed 0.5.3. No worries if it's currently not working, no rush :)

[porres]

I come from many years of using Max, so using trigger this way is in all of my patches and my workflow

funny... I tried but I couldn't see the advantage for having an extra object that works like this... it never got into my workflow, so I deleted my external with no mercy :/

[porres]

@tmhglnd I added a [datetime] object to ELSE, wait for the next release

[jyg]

Catching mouse events with superimposed widgets I know that JUICE behaviour with superimposed widgets is inverted related to Tcl/Tk (i.e. the top-most drawn widget catches mouse events, wheras in pd vanilla it is the widget in background that catches mouse events). Unfortunately, I use this tcl/tk behaviour to create custom displays in vanilla. I can figure this JUCE behaviour cannot be changed. However, would it be possible to prevent cnv widgets from capturing mouse events ? This way, it would be possible to hide -say- a slider behind a cnv and create a customised interactive display.