plugdata-team
Feature requests
If you have any ideas for features you'd like to see, drop them here!
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.
- More audio outputs and inputs. Probably 16 is enough.
- Copy/Cut/Paste across PlugData instances
- MIDI input for FX version (for MIDI controlled FX)
- Audio inputs for Instrument versions (for audio controlled things like vocoders or audio modulation of oscillators etc...)
- At least 256 automatable parameter. But i think that should be a kind of "dynamic" number
- Save patches in the actual DAW file (so when the DAW project is open again patches are all loaded)
@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.
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.
- More audio outputs and inputs. Probably 16 is enough.
- Copy/Cut/Paste across PlugData instances
- MIDI input for FX version (for MIDI controlled FX)
- Audio inputs for Instrument versions (for audio controlled things like vocoders or audio modulation of oscillators etc...)
- At least 256 automatable parameter. But i think that should be a kind of "dynamic" number
- Save patches in the actual DAW file (so when the DAW project is open again patches are all loaded)
- Time sync with host (samplePos, ppqs, time signature, play/stop status, etc...)
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.
- Add faustgen~ ( https://github.com/CICM/pd-faustgen )
- Add pd-fttease
- 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)
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
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.
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
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.
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!
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.
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 ;)
@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.
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!
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?
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
we can maybe have an online "reference" like I'm planning on doing with vanilla
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.
@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/
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.
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.
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.