Comments (16)
I may have found a solution...
If we define PD_THIS with a function, get_this() which is defined in an .c file instead of a header, we can make any new externals that are compiled work both with and without PDINSTANCE.
I still need to investigate this further, but it would mean that externals only need to be recompiled against the new header in order to work, without having to change any source code at all. If it works, I hope the pd devs will accept this change. It would also mean that Camomile could start supporting this (also by just recompiling!).
Because the PD_THIS external in existing externals already points to the &pd_maininstance symbol (which still exists), it shouldn't break anything.
EDIT: Okay, so I think the only problem would be that newly built externals would stop working in old pd versions. So maybe this is not a perfect solution after all... It's an interesting discussion. It might be possible to add some kind of fallback mechanism for this.
EDIT 2: I've managed to make externals built with new the PDINSTANCE system work in an unmodified pd-vanilla! Basically, you can just add a backup definition for these functions into your external, since dlopen won't overwrite these when it finds a duplicate. This can be done automatically in m_pd.h.
from plugdata.
Externals now work in the standalone! I'll have to do some more testing but it's looking good.
For the plugin, support for externals is still a problem because we need to have multiple instance support.
PS: For M1 Mac users: remember to use PlugData in Rosetta if you want support for x64 externals.
from plugdata.
Do these libraries load on vanilla pd? PlugData has the same core as pd-vanilla, it's possible that some externals for purr-data don't work because they use a different pd core.
from plugdata.
They load in vanilla.
from plugdata.
Then they should load in PlugData, I'll check it out!
from plugdata.
This problem is caused by the fact that the externals are compiled without the PDINSTANCE and PDTHREAD flag, while PlugData needs to be compiled with those flags. I need to compile with PDINSTANCE because we need to be able to use multiple instances to make it work as a plugin. Camomile suffers from the same issue, there's unfortunately not much I can do about it.
I'll leave the issue open, so people can see that this doesn't work yet.
from plugdata.
Hi,
I still have the error in Standalone :
from plugdata.
Looks like I made a mistake in the cmakefile, I'll fix it right now.
from plugdata.
Can reproduce that it doesn't work on linux
from plugdata.
It works now! Turns out I needed to pass the -export-dynamic linker flag on Linux to get this kind of backwards linking to work.
from plugdata.
I don't know if you're building from source, but if you're not I'll create a release soon when I'm done with some other bug fixes!
from plugdata.
I see that windows has the same problem (unfortunately not with the same solution), so I'll look into that as well. My bad for assuming that it'd just work on all platforms, oops!
from plugdata.
I confirm it works on linux. Thank you !
from plugdata.
Edit 2 almost deserve a "wont fix" tag removal from the issue :-D
Great stuff tho! Finger crossed
from plugdata.
I may have found a solution...
If we define PD_THIS with a function, get_this() which is defined in an .c file instead of a header, we can make any new externals that are compiled work both with and without PDINSTANCE.
I still need to investigate this further, but it would mean that externals only need to be recompiled against the new header in order to work, without having to change any source code at all. If it works, I hope the pd devs will accept this change. It would also mean that Camomile could start supporting this (also by just recompiling!).
Because the PD_THIS external in existing externals already points to the &pd_maininstance symbol (which still exists), it shouldn't break anything.
EDIT: Okay, so I think the only problem would be that newly built externals would stop working in old pd versions. So maybe this is not a perfect solution after all... It's an interesting discussion. It might be possible to add some kind of fallback mechanism for this.
EDIT 2: I've managed to make externals built with new the PDINSTANCE system work in an unmodified pd-vanilla! Basically, you can just add a backup definition for these functions into your external, since dlopen won't overwrite these when it finds a duplicate. This can be done automatically in m_pd.h.
Hi, can you elaborate a little on where to find m_pd.h. ? And could you upload your .h file from your system?, as a reference off course, as I understand, it would need the specific externals I would install...
from plugdata.
The m_pd.h file I use should be identical to the one in the pure-data version that is reported in the console. If you want to be sure though, it should be located at Libraries/pure-data/src/m_pd.h, relative to plugdata's repo folder. Hope that helps!
from plugdata.
Related Issues (20)
- GEM Library is crashing when creating a window (Plugdata version 0.8.3, GEM version 0.94) HOT 4
- Bug: unable to build due to undefined reference to `scope_tilde_setup' HOT 1
- Develop `Branch` - Mouse Position Issue HOT 5
- Plug Data (Standalone or plugin versions) don't open on some apple silicon macs after crash HOT 2
- PlugData 0.9.0 nightly built, can't open [oscope~] from Show Object Browser HOT 2
- Number box doesn't show numbers HOT 11
- Switch focus to newly opened patch HOT 1
- keyboard gets inactive while clicking and holding HOT 1
- [Feature request][External] ReacTIVision TUIO client HOT 2
- [bug] patch that is closed still running in the background HOT 5
- [feature] Implement the note on/off "extra byte" for microtuning HOT 11
- [0.9.0-test] The color of object's name is not updated after switching themes. HOT 3
- [bug} Settings and Compile menus make entire program stuck "on top" HOT 3
- [bug] file dialog doesn't close when compile dialog is closed HOT 3
- wont run on ipad air 1st gen ios 12.5 HOT 3
- Button widget doesn’t respond to Toggle message HOT 4
- GEM getting error while creating a window inside Cubase
- Rendering / Disabling Track / Exporting VST3 HOT 6
- [bug] palette menu renders below canvas
- Internal GM Synth outputs weird noises
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from plugdata.