Feature requests about plugdata HOT 282 OPEN

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

from plugdata.

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!

from plugdata.

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.

from plugdata.

@jyg I recently fixed this behaviour for graphs, so you can click through those. I think it's a good idea to allow that for [cnv] as well, like you suggested. I'll work on it!

@charlesneimog Good idea, will be done!

from plugdata.

@jyg [cnv] now no longer intercepts mouseclicks, so you can put objects behind it and still use them, just like in Pd-vanilla.

@charlesneimog Zoom level will be saved now!

from plugdata.

Open Patches from Explorer (Windows).

For now it is not possible to open patches from Windows Explorer, this would be great!

Thanks, I didn't know it was broken, fix coming soon!

from plugdata.

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)

from plugdata.

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

from plugdata.

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

from plugdata.

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

from plugdata.

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.

from plugdata.

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.

from plugdata.

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

from plugdata.

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.

from plugdata.

• Select and Copy from console

from plugdata.

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.

from plugdata.

Deken support is coming!

from plugdata.

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.

from plugdata.

Hi,
this is the named pan in CAD:

from plugdata.

@FlachyJoe Like this?

from plugdata.

Done!

from plugdata.

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

from plugdata.

Keyboard shortcut to open floating add menu
I would love to have a quick way to open the "add" menu in a fashion similar to how blender does it. You would hit shift+a (or some other shortcut) and the add menu would popup under your cursor. I'm used to the ctrl+number shortcuts from pure data but I still think this would greatly improve the workflow, here's a little screenshot showcasing what I mean :)

from plugdata.

it offers near perfect vanilla compatibility with a very nice GUI.

I believe it offers a perfect 100% vanilla compatibility. It only differs in the GUI.

The only thing that's incompatible is externals that draw their own UI with tcl/tk, which is the same for Purr-Data. For ELSE/cyclone we can work around it, by rewriting the UI with JUCE.

There might be other small incompatibilities, but those would be considered bugs that need to be fixed. Pd is very flexible so it's hard to estimate how good compatibility is, but I think it's pretty good right now.

from plugdata.

In Libraries/CMakeLists.txt, there's a target named "externals". If you add a cmake subproject for the external, make sure it creates a static library instead of a dynamic one, and then add the target to "externals", it should link correctly. Then, you need to call the setup function for your external in x_libpd_multi.c

There is unfortunately no documentation for this yet. Right now, plugdata leaves a lot to be desired, documentation wise.

pd-lua can be linked against liblua statically, the other deps are just system libraries.

Nice, that makes it much easier.

Concerning pd-faustgen, it needs the LLVM dylib, but it should be possible to include that with the external (as I've done in my M1 build) so that it can just find it on is own. So AFAICT no need to link plugdata against LLVM (which is a pretty hefty dependency). Or am I overlooking something?

I think the problem here is that pd-faustgen must be linked to plugdata statically for thread-local storage to work. When you link pd-faustgen statically, it's no longer possible to link LLVM to the external because the external is baked into plugdata's binary now. So it will have to be linked to plugdata at startup to make sure it doesn't complain about missing symbols. It's still totally possible to include it, I'm just not looking forward to doing it on 3 different platforms ;)

The result will be worth it though. I'll take a look soon, and I'll also try to help @porres with including it in ELSE, when I have some time.

from plugdata.

Finding a way to make externals work in the plugin could be a great way to distribute extra features for the plugin without complicating plugdata's build system too much.

I'd say that It's the holy grail of making embedded libpd applications really practical. Maybe you want to pursue a Master/PhD thesis project on that? ;-) Then again plugdata itself is already a major achievement that should win you some awards...

from plugdata.

I think the inclusion of pd-lua makes a lot more sense than pd-faustgen for now, since it's so much simpler to include it.

I actually made some progress on that front, now that my compilation probs are sorted out (or at least circumvented). I was able to link a static build of pd-lua into the vst plugin with these changes:

commit 5621d85e7e54c1d945de3c206a04deea26736852
Author: Albert Gräf <[email protected]>
Date:   Mon Jan 2 11:48:51 2023 +0100

    Add pdlua (WIP).

diff --git a/Libraries/CMakeLists.txt b/Libraries/CMakeLists.txt
index 38e195c4..f113e20c 100755
--- a/Libraries/CMakeLists.txt
+++ b/Libraries/CMakeLists.txt
@@ -360,8 +360,10 @@ set_target_properties(pd-multi PROPERTIES POSITION_INDEPENDENT_CODE ON)
 set_target_properties(externals PROPERTIES POSITION_INDEPENDENT_CODE ON)
 set_target_properties(externals-multi PROPERTIES POSITION_INDEPENDENT_CODE ON)
 
-target_link_libraries(externals ${SFONT_LIBS})
-target_link_libraries(externals-multi ${SFONT_LIBS})
+set(PDLUA_LIBS "/Users/ag/Sources/github/pd-lua/pdlua.a;/opt/homebrew/lib/liblua.a")
+
+target_link_libraries(externals ${SFONT_LIBS} ${PDLUA_LIBS})
+target_link_libraries(externals-multi ${SFONT_LIBS} ${PDLUA_LIBS})
 target_include_directories(externals PRIVATE ${SFONT_INCLUDE_DIR})
 target_include_directories(externals-multi PRIVATE ${SFONT_INCLUDE_DIR})
 # ------------------------------------------------------------------------------#
diff --git a/Libraries/libpd/x_libpd_multi.c b/Libraries/libpd/x_libpd_multi.c
index c770532a..e400bba0 100644
--- a/Libraries/libpd/x_libpd_multi.c
+++ b/Libraries/libpd/x_libpd_multi.c
@@ -737,6 +737,13 @@ void xselect_tilde_setup();
 void xselect2_tilde_setup();
 void zerocross_tilde_setup();
 
+void pdlua_setup();
+
+void libpd_init_pdlua(void)
+{
+    pdlua_setup();
+}
+
 void libpd_init_else(void)
 {
     above_tilde_setup();
diff --git a/Libraries/libpd/x_libpd_multi.h b/Libraries/libpd/x_libpd_multi.h
index 7be17cb3..5d1244a0 100644
--- a/Libraries/libpd/x_libpd_multi.h
+++ b/Libraries/libpd/x_libpd_multi.h
@@ -15,6 +15,7 @@ extern "C" {
 void libpd_multi_init(void);
 void libpd_init_else(void);
 void libpd_init_cyclone(void);
+void libpd_init_pdlua(void);
 
 typedef void (*t_libpd_multi_banghook)(void* ptr, char const* recv);
 typedef void (*t_libpd_multi_floathook)(void* ptr, char const* recv, float f);
diff --git a/Source/Pd/PdInstance.cpp b/Source/Pd/PdInstance.cpp
index e6e1bc5d..5e4e366d 100644
--- a/Source/Pd/PdInstance.cpp
+++ b/Source/Pd/PdInstance.cpp
@@ -119,6 +119,7 @@ Instance::Instance(String const& symbol)
 
     libpd_init_else();
     libpd_init_cyclone();
+    libpd_init_pdlua();
 
     m_midi_receiver = libpd_multi_midi_new(this, reinterpret_cast<t_libpd_multi_noteonhook>(internal::instance_multi_noteon), reinterpret_cast<t_libpd_multi_controlchangehook>(internal::instance_multi_controlchange), reinterpret_cast<t_libpd_multi_programchangehook>(internal::instance_multi_programchange),
         reinterpret_cast<t_libpd_multi_pitchbendhook>(internal::instance_multi_pitchbend), reinterpret_cast<t_libpd_multi_aftertouchhook>(internal::instance_multi_aftertouch), reinterpret_cast<t_libpd_multi_polyaftertouchhook>(internal::instance_multi_polyaftertouch),

It's still a bit rough, as I'm building pd-lua out-of-tree, but we can worry about integration later. The problem is that it doesn't seem to work. I can see that the symbols of pd-lua and liblua are in the plugin binary, so I'm pretty sure that pdlua_setup is being called. I use Bespoke as a host, but creating a plugdata instance doesn't show anything in the console log. (Normally it should display some logpost messages there if it starts up successfully.) I suspect that this is because the external can't find its pd.lua file that it tries to load in pdlua_setup. Most of the external is actually implemented in Lua itself, so if it cannot find this file then nothing will work. But I don't see any error messages from the setup routine either.

I can probably get this sorted out; I see that cmake generates a Resources/Filesystem.zip file which gets populated with data files to be included in the plugin, so I just need to figure out a way to add pd-lua's support files there.

But first I need to be able to debug the setup function to figure out what exactly is going on there. Does plugdata provide any special functions that I can call for printing stuff in the console log, so that I don't have to resort to printf? Is logpost supposed to work during startup?

from plugdata.

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.

from plugdata.

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.

from plugdata.

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)

from plugdata.

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

from plugdata.

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 ;)

from plugdata.

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

from plugdata.

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!

from plugdata.

I have no idea what you mean :/

from plugdata.

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?

from plugdata.

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

from plugdata.

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

from plugdata.

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

from plugdata.

then ship the html

from plugdata.

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.

from plugdata.

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

from plugdata.

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.

from plugdata.

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.

from plugdata.

Hi,

• does 7291f3f 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

from plugdata.

• 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

from plugdata.

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.

from plugdata.

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

from plugdata.

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!

from plugdata.

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.

from plugdata.

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.

from plugdata.

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

from plugdata.

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.

from plugdata.

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]

from plugdata.

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

from plugdata.

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

from plugdata.

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

from plugdata.

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.

from plugdata.

Hi,

I'd like to request a way to save my preferences about zoom (about the software, not the patches!)

Just that! :)

from plugdata.

Is there a way to programmatically open a subpatch / abstraction / table / text ?
In Pd Vanilla this is achieved by sending a [vis 1( message --or [click( for table and text objects-- to the target object.
This would be nice in order to adapt projects such as audiolab or automatonism that use frequently this popup feature.
Thanks ;-)

from plugdata.

Other request :
Is there a way to force redrawing of a patch ?
If I do dynamic patching and insert a new object in a patch by message, the display has to be refreshed in order to make the new object appear.
Once again, Thanks ;-)

from plugdata.

Is there a way to programmatically open a subpatch / abstraction / table / text ?

Hi! Unfortunately not yet: it might be possible to implement this, I'll investigate it!

Other request : Is there a way to force redrawing of a patch ? If I do dynamic patching and insert a new object in a patch by message, the display has to be refreshed in order to make the new object appear. Once again, Thanks ;-)

This is a known issue, I could add a manual refresh button, but I also have an idea for how we can solve this in a better way. Another problem is that PlugData creates an invisible comment object where it stores the segmented connection paths, so all the indices will be offset by one when doing dynamic patching. I'm planning to add a "dynamic patching mode" where the patch will get updated when it changes internally, and segmented connections will be disabled.

from plugdata.

Open Patches from Explorer (Windows).

For now it is not possible to open patches from Windows Explorer, this would be great!

from plugdata.

It think it would really cool to have some kind of application scripting interface. This could be along one or more of these:

• Use an in-app console via some embedded scripting language like lua or javascript

• Use the app via the terminal using an exposed scripting api like a python api where some c++ classes are wrapped using pybind11 or such. If you go down this route, there's a project called binder which can help generate such wrapper code by parsing c++ code.

• Use a REST-api exposed by PlugData, which then allows any language to interface with the app.

etc...

from plugdata.

@shakfu That would be very nice! I'm looking at including Ofelia at some point in the future, that already comes with some Lua capabilities. Maybe I could expand that to also be able to interact with more parts of the app. The other options you mention also sound good, but would probably be a lot more work.

I won't have time for this soon, since there are still some more urgent issues to handle, but I'll keep it in mind for somewhere in the future!

from plugdata.

I think PlugData power is vanilla compatibility so I'm not comfortable with included script idea.
It's quiet easy to implements in what ever language you want a FUDI server to deal with PD control messages throw [netsend] [netreceive] or an OSC server to process audio data.

For your benefit I share a Python/Qt FUDI server here: https://github.com/FlachyJoe/FCPDWorkbench/blob/main/fcpd/pdserver.py (however it needs to be FreeCAD purged to work outside this project).
I also work on automatic patch creation in python, see: https://github.com/FlachyJoe/FCPDWorkbench/blob/main/dev_tools/python/PdParser.py

from plugdata.

I think PlugData power is vanilla compatibility so I'm not comfortable with included script idea. It's quiet easy to implements in what ever language you want a FUDI server to deal with PD control messages throw [netsend] [netreceive] or an OSC server to process audio data.

For your benefit I share a Python/Qt FUDI server here: https://github.com/FlachyJoe/FCPDWorkbench/blob/main/fcpd/pdserver.py (however it needs to be FreeCAD purged to work outside this project). I also work on automatic patch creation in python, see: https://github.com/FlachyJoe/FCPDWorkbench/blob/main/dev_tools/python/PdParser.py

good point, allowing the Lua to interact with the GUI would break compatibility (compared to Ofelia on vanilla). Some of the other ideas could be implemented entirely on the GUI side, and not break any compatibility.

from plugdata.

@timothyschoen and @FlachyJoe

I agree that compatibility is an important goal, but an improved scripting interface (just like an improved GUI interface) will not break compatibility provided the file format does not change.

from plugdata.

On scripting question: for maximum compatibility, one could stay close to builtin libpd scripting. This may or may not be relevant here, but I had a crack, some time ago, at wrapping the cpp libpd api using pybind11 and binder mentioned above which you can find here.

from plugdata.

First, a happy new year to everyone! :)

@timothyschoen, sorry for being so late to the party after you mentioned plugdata to me during my presentation at HKU in June 2022. I finally got around to it, though. ;-) PlugData is amazing, I really enjoy using it.

What I miss, though, is the ability to define startup libs, specifically for plugin loaders like pd-lua. Sure, it's possible to use something like [declare -lib pdlua] in a patch, but having to add that to each and every patch using Lua externals is a bit of a chore. Maybe you could add a list of startup libs to the PlugData settings, like we have in Pd and Purr Data? That would be much appreciated, thanks!

from plugdata.

Talking about plugin loaders, the same is true for faustgen2~ which has been mentioned above. This external also registers its own plugin loader so that Faust programs can be instantiated by simply typing their name. Currently, in order to load the sample patches included in faustgen2~ I have to first load a helper patch consisting of just [declare -lib faustgen2~]. Which is a small inconvenience, but still.

As an aside, in case you were wondering, yes, faustgen2~ actually works in PlugData. I just gave it a go, here it runs on my MacBook M1 Air in the stand-alone PlugData app:

In case anyone wants to give it a go, my native M1 build can now be found at https://github.com/agraef/pd-faustgen/releases/tag/2.0.2

from plugdata.

Hi @agraef, PlugData ships with my ELSE library (and not really mine Cyclone) and @timothyschoen has mentioned he's not a fan of adding yet more dependencies. And, what you can see, is that one can find the way loading externals themselves. Nonetheless, what's been happening is that we've worked together to add objects to ELSE, like the polyblep oscillators also mentioned above and other new externals.

So, there was an idea that we'd also add a faust~ object to ELSE based on your (yourself and pierre's) work. No real work has been done besides slightly thinking and mentioning about it in the plugdata's discord channel. I just thought I'd mention it even though we have no idea we'll actually have time to pursue it or if there will be other challenges. One way or another I'd like to ask why didn't you use pdlibbuilder for faustgen2~?

thanks

from plugdata.

@timothyschoen has mentioned he's not a fan of adding yet more dependencies.

That's not what I suggested. I understand that plugdata is designed to be lean and mean, and I think that's a good idea. I'd like to have an additional startup libs option in plugdata's settings, that's all. That makes it easier for users to add their own preloaded libs if needed. And besides, plugdata already supports Deken, so the intention for plugdata clearly is to be extensible, and thus having that startup libs option seems sensible, too.

from plugdata.

Of course you did not suggest this and your actual suggestion was clear before ;)

I was just informing you of previous plans/discussion and asking about something else... I thought it was clear.

from plugdata.

First, a happy new year to everyone! :)

@timothyschoen, sorry for being so late to the party after you mentioned plugdata to me during my presentation at HKU in June 2022. I finally got around to it, though. ;-) PlugData is amazing, I really enjoy using it.

What I miss, though, is the ability to define startup libs, specifically for plugin loaders like pd-lua. Sure, it's possible to use something like [declare -lib pdlua] in a patch, but having to add that to each and every patch using Lua externals is a bit of a chore. Maybe you could add a list of startup libs to the PlugData settings, like we have in Pd and Purr Data? That would be much appreciated, thanks!

Happy new year to you too!

Glad you enjoy using it, nice to hear! I should definitely add the startup libs, somehow I forgot about that. It's an essential feature so I'll make sure to add it before the next release.

I've messed around with faustgen2~ in plugdata after the presentation at HKU, my experience back then was that it worked, but I couldn't get any user interfaces to load. It looks like you have that working in the screenshot, did you have to do anything special to get it to work?

Back then I used it with Rosetta, I'll definitely try out the M1 version.

from plugdata.

@porres: Ok. I must admit that I'm guilty of just jumping into this thread without reading through it in its entirety. ;-)

After reading some more, I also understand the difficulties involved in making existing externals work with PlugData much better, and why some (many?) of them won't work in the plugin version where they need to operate in a multi-instance, multi-threaded environment.

Unfortunately, I think that this also applies to both pd-lua and pd-faustgen. Both use a global single instance of a language environment (the Lua interpreter in the former, the Faust compiler in the latter case). Thus they'd need a complete redesign to make them run in such an environment.

Still, I think that a startup libs option would be beneficial for the stand-alone PlugData users at least. There's always audio and MIDI loopbacks in order to communicate with a DAW. Of course you could then use Pd (or Purr Data) instead, but I can see why some people might actually prefer PlugData because it offers near perfect vanilla compatibility with a very nice GUI.

from plugdata.

Hi @timothyschoen!

I've messed around with faustgen2~ in plugdata after the presentation at HKU, my experience back then was that it worked, but I couldn't get any user interfaces to load. It looks like you have that working in the screenshot, did you have to do anything special to get it to work?

The faustgen2~ guis are just ordinary one-off subpatches, nothing special about them.

You first need to create a one-off subpatch and then enter the name of that subpatch as a creation argument after the name of the Faust program. E.g., [pd synth], then [organ~ synth] (or [faustgen2~ organ synth]) will do the trick. The external will then populate the subpatch and define its gop area.

from plugdata.

it offers near perfect vanilla compatibility with a very nice GUI.

I believe it offers a perfect 100% vanilla compatibility. It only differs in the GUI - and how you can run it as a plugin (of course)

from plugdata.

The only thing that's incompatible is externals that draw their own UI with tcl/tk

Good point. I am thinking of a hack, what if you use the [pd~] object to open "real" Pd? I guess that could potentially work for Purr Data as well. Then these GUI externals could be run inside Vanilla, huh?

from plugdata.

One way or another I'd like to ask why didn't you use pdlibbuilder for faustgen2~?

@porres, sorry, I overlooked that question. As you noted, faustgen2~ is a fork of Pierre Guillot's faustgen~ and thus it inherited Pierre's cmake-based build system. Which makes sense if you have to deal with heavy and platform-dependent 3rd party libraries like LLVM.

from plugdata.

The only thing that's incompatible is externals that draw their own UI with tcl/tk

Good point. I am thinking of a hack, what if you use the [pd~] object to open "real" Pd? I guess that could potentially work for Purr Data as well. Then these GUI externals could be run inside Vanilla, huh?

That could be possible, but it would require shipping tcl/tk with plugdata/purr-data. I believe tcl/tk also has an option to render to an image, so you could possibly use that. This would be very complicated though, the chance that you run into issues that are impossible to overcome are very large. Also, you can't just open the patch in Pd-vanilla, because then you'd just have two separate patches open that are unable to communicate with eachother.

I know that Pd-vanilla is writing a new API for graphics right now, if externals implement their drawing through that API (which I hope will happen in the future), it would be much simpler to make this work.

from plugdata.

Thinking about pd-lua some more, it might be possible to make it work in a thread-safe fashion by making the global interpreter variable thread-local. There is probably some more global data in that external, but hopefully it can be dealt with in a similar fashion. So there's an avenue towards plugdata plugin compatibility there, but it's going to be some work.

Taking another brief look at the pd-faustgen source, it seems to keep all the Faust compiler related data structures either in the Pd object struct or in local variables. Thus it should be ok -- a simple recompile with PDINSTANCE/PTHREAD might be all that's needed (fingers crossed).

from plugdata.

Thinking about pd-lua some more, it might be possible to make it work in a thread-safe fashion by making the global interpreter variable thread-local. There is probably some more global data in that external, but hopefully it can be dealt with in a similar fashion. So there's an avenue towards plugdata plugin compatibility there, but it's going to be some work.

Taking another brief look at the pd-faustgen source, it seems to keep all the Faust compiler related data structures either in the Pd object struct or in local variables. Thus it should be ok -- a simple recompile with PDINSTANCE/PTHREAD might be all that's needed (fingers crossed).

That could work, we'd need to link pd-faustgen and pd-lua statically to plugdata (for thread-local storage to work), and then link all other dependencies to plugdata dynamically. Unfortunately that means we can't link the dynamic library at runtime, because then symbols would be missing at startup.

from plugdata.

That could work, we'd need to link pd-faustgen and pd-lua statically to plugdata (for thread-local storage to work) ...

How does one link to plugdata, do you have documentation on that somewhere in the wiki?

... and then link all other dependencies to plugdata dynamically.

pd-lua can be linked against liblua statically, the other deps are just system libraries.

Concerning pd-faustgen, it needs the LLVM dylib, but it should be possible to include that with the external (as I've done in my M1 build) so that it can just find it on is own. So AFAICT no need to link plugdata against LLVM (which is a pretty hefty dependency). Or am I overlooking something?

from plugdata.

That could be possible, but it would require shipping tcl/tk with plugdata/purr-data.

Tim, the way I reffered to in Camomile would be the ability to actually call a "real" Pd app. Camomile was doing it by also shipping Pd-Vanilla with it, but we could also require power users to install Pd-Vanilla and call it from within PlugData.

Do you follow me? Might be good for this and other edge cases ;) and maybe the same could be done with purr/l2ork

from plugdata.

The only thing that's incompatible is externals that draw their own UI with tcl/tk

For ELSE/cyclone we can work around it, by rewriting the UI with JUCE.

luckily there aren't that many GUI externals out there and I am in the game for offering alternatives for all of them that "makes sense" in ELSE

from plugdata.

I think the problem here is that pd-faustgen must be linked to plugdata statically for thread-local storage to work.

Ah ok, after looking at vanilla's m_pd.h I understand now that Pd (and thus PlugData) uses TLS itself in order to implement thread-safety if PTHREAD is set at compilation time. Yeah, I can see perfectly well now why you can't just run any old externals in the plugin version of PlugData. ;-)

Just to be clear, I'm really happy with PlugData as it is. I'm definitely not suggesting that we need everything and the kitchen sink to work inside the plugin. Quite the contrary -- as a plugin you want PlugData to be lean and mean, after all many such plugins might run alongside each other in your DAW. Also, it seems to me that PlugData already has the stuff it needs to cover most common uses as a plugin. Alexandre's ELSE really seems to be very comprehensive. (If I'd ask for anything there, it would be to include some of mrpeach's objects for OSC data decoding and encoding.)

Of course, I was also happy to find that the standalone can indeed run the extra externals that I use without much fuss. That's all I'd have asked for -- and the startup libs option. ;-)

Does it make sense to have faustgen and maybe pd-lua included in the plugin? I'd certainly use Lua if it was available there. The advantage there is, once you've learned pd-lua (which is quite easy) you can use it as your control scripting language anywhere inside PlugData, and not have to rely on what scripting solution your plugin host happens to provide.

With faustgen I'm not so sure, because there are plenty of other possibilities. Faust programs can be compiled to various plugin formats and run alongside PlugData in a DAW or a modular host like Bespoke. I see faustgen more as a tool for learning, teaching, and prototyping Faust DSPs, and for that purpose it works just fine in the standalone. But that's just my take on it, YMMV.

In any case, having to link externals statically into PlugData to make them work in the plugin isn't a strategy that's going to scale up IMHO. You can do that for a small handful of externals, but with each new addon module you also drag in technical debt, until your project becomes a behemoth like Pd-extended and its children. ;-)

BTW, Tim, in #34 you sketched out a different solution where you'd just recompile an external with a special m_pd.h header file and maybe some changes to the plugin source. Would that work without having to link against PlugData statically? Now that might be a viable approach, as it leaves the support burden with the plugin developer or maintainer who wants her or his external to work with PlugData.

from plugdata.

If I'd ask for anything there, it would be to include some of mrpeach's objects for OSC data decoding and encoding

Bring it on :) I thought about it already. But it would be much simpler and just easier to use OSC objects, but still more powerful than oscparse/oscformat

As for lua and faust in ELSE, seems like it's overkill but this is where it is heading now and I think it'd be good to have yet more options for it in vanilla. I don't see faustgen2~ in deken by the way, faustgen~ doesn't really work. I guess there's support for lua in ofelia? Ceammc has faust~ but stopped working in Vanilla 0.52 and hasn't been fixed yet?

Where I am getting at is that maybe the more the merrier and I can compromise to make my stuff portable and easily available for Vanilla. If this is also desired for PlugData, everybody is happy and looks like something we could do.

from plugdata.

Ofelia looks interesting, but it's another big external which drags in another large library (openFrameworks). It's certainly overkill for just being able to run Lua inside Pd. Claude Heiland-Allen's pd-lua has a much smaller footprint even with liblua linked statically into it, is easy to compile, with no dependencies other than Pd and Lua. That's not an accident; Lua is designed from the ground up to be easily embeddable.

Not heeding Tim's warnings, I just went ahead and tried to build pd-lua as a shared lib with -DPDINSTANCE -DPDTHREAD and backlinking it to the plugdata executable, and sure enough it didn't work. ;-)

ld: illegal thread local variable reference to regular symbol _pd_this for architecture arm64

Ok, I guess I'll have to try the method of linking statically with plugdata suggested above.

from plugdata.

I got pd-lua to build a static archive with the right compilation options (-DPDINSTANCE -DPDTHREAD), that was easy.

But plugdata doesn't compile for me on macOS, neither on Intel nor M1. :(

EDIT: Removed the lengthy report from this thread, instead I documented my compilation woes here: #299. Sorry for the noise.

I guess that I'll have to give up for now. If anyone has gotten this to compile on the Mac, please advise. I could use some help there. :) I'll also try a build on Linux later.

from plugdata.

Lua is something that has been discussed to be supported in vanilla already...

We can start by providing a well resolved and modern pdlua object in ELSE. There's one in deken but from extended era...

Afterwards we can try a PR to include it in Vanilla

from plugdata.

Well, I maintain the latest version here: https://github.com/agraef/pd-lua. That's been updated to Lua 5.3 and 5.4 and is also the version included in Purr Data. It also works in vanilla and in plugdata standalone.

The one from Deken probably is the version maintained for Debian by zmoelnig. Last time I checked, this would only support Lua 5.2 which is ancient.

But the real problem for inclusion in plugdata will be to make it thread-safe, so that it not only compiles, but actually works in a multi-instance, multi-threaded environment. That work still needs to be done.

from plugdata.

woah I had written a long response yesterday, but forgot to hit send...

@agraef I feel the same, I think the inclusion of pd-lua makes a lot more sense than pd-faustgen for now, since it's so much simpler to include it.

Unfortunately the solution I found in #34 turned out the be a dead-end. One thing I've been thinking about recently, is hiding pd_this behind a function pd_this(), so that the TLS access can be hidden behind a function, and therefore could work inside a dynamic library/external. That way, you could at least compile externals that can work inside the plugin version. I should propose this in the pd-dev mailing list.

Finding a way to make externals work in the plugin could be a great way to distribute extra features for the plugin without complicating plugdata's build system too much. If I end up porting Ofelia to plugdata at some point, I would also prefer doing it that way.

In any case, having to link externals statically into PlugData to make them work in the plugin isn't a strategy that's going to scale up IMHO. You can do that for a small handful of externals, but with each new addon module you also drag in technical debt, until your project becomes a behemoth like Pd-extended and its children. ;-)

Totally agree, right now [sfont~] is the only part of plugdata with a complicated build system, and it's also the only part of compilation that sometimes randomly fails, as you have noticed already. I'd really like to keep everything as simple as possible.

from plugdata.

One thing I've been thinking about recently, is hiding pd_this behind a function pd_this(), so that the TLS access can be hidden behind a function, and therefore could work inside a dynamic library/external.

This sounds like a good solution, but I think that it might be a tough sell upstream. I'm not sure how TLS is implemented on the various different platforms but, generally speaking, the overhead of an extra function call there might seem a bit excessive and have a noticeable impact on performance. Unless you can make sure that the overhead will only apply for externals compiled specifically for libpd.

from plugdata.

Is logpost supposed to work during startup?

Looks like I have to move the call to pdlua_setup near the end of the Instance::Instance() constructor, where all the receivers and triggers have already been set up. Anything posted before that is simply lost. That's probably how it is intended to be.

Anyway, I can see now that my theory was correct:

Kind of "first light" of pd-lua in the plugin, although it's not working yet. But at least I have a way to debug it now. ;-)

Ok, now I just need to figure out how to get stuff into Resources/Filesystem.zip and make pd-lua find it during setup.

from plugdata.

Ok, I see that there's a Python script which packages up all the extra stuff. This is easily modified, but I don't understand how and when those files are transferred from the plugin to ~/Library/plugdata where apparently those files end up. @timothyschoen, can you explain?

from plugdata.

Also, I noticed that I'm getting this error when compiling the standalone:

[ 42%] Linking CXX executable /Users/ag/Sources/github/plugdata/Plugins/Standalone/plugdata.app/Contents/MacOS/plugdata
Undefined symbols for architecture arm64:
  "_pd_this", referenced from:
      _pdlua_loader_fromfd in pdlua.a(pdlua.o)
ld: symbol(s) not found for architecture arm64

The plugins build alright.

Do I have to build a separate version of pdlua.a without PDINSTANCE PDTHREAD for the standalone?

from plugdata.

Ok, I have this basically working now. To test this with one of my Lua externals, mdnsbrowser which connects to TouchOSC via Bonjour, I really need some OSC objects now. I'm currently using mrpeach for that, but of course that won't work in the plugin. So what is everybody using? Do we only have oscparse and oscformat right now??

from plugdata.

Do we only have oscparse and oscformat right now

yup, what exact functionality you need the most from mr peach's objects? I can create a quick alternative for ELSE

from plugdata.

yup, what exact functionality you need the most from mr peach's objects? I can create a quick alternative for ELSE

Please do, that would be a heaven-sent. :) Basically, I need udpsend, udpreceive, packOSC, unpackOSC, and routeOSC. mrpeach's latest source is up somewhere on GH, I believe.

from plugdata.