plugdata
plugdata copied to clipboard
plugdata-team
Problems with ELSE in v0.5
I'm releasing a new version today, I'll make sure it has the latest ELSE!
What is the difference between the objects in the Camomile folder and the Abstractions folder? Which do you think would be best for PlugData?
the ones in camomile are proper for camomile :) it doesn't use the 'else/' prefix for objects as camomile can't sort that out, instead they just use [declare -path else], which is needed for the abstractions in ELSE, which should be placed in a folder called 'else'. So just move the files from the 'camomile' folder to a folder called 'else' that PlugData can find via [declare -path]
tested version 0.5:
-
I can't open help files of ELSE
-
the object else/message doesn't load becuase you created an object to load pd message boxes
Unfortunately I've found more issues with ELSE when loading the All_Objects patch.
I completely missed that the help files are gone, I'll take a look at it. v0.5 was such a big release that I'm kinda expecting that I have to create a small patch soon with some fixes. The message one is a bit tricky, but I'll see if I can work around it.
Unfortunately I've found more issues with ELSE when loading the All_Objects patch.
let's fix them all
Definitely, almost all are just my mistake
-
I forgot to initialise the buffer object, now fixed. Also I assumed that each .c file has one class in it so I hope I'm not missing out on any other init calls.
-
"delread4~: 1346-buf: no such delwrite~" gets spammed to the console causing PlugData to freeze. There are possibly more issues but it's impossible to find out once this happens
-
After deleting All_objects, the memory footprint has increased by about 100mb which indicates that some objects have (pretty big) memory leaks, this also happens in pd-vanilla. I'll try to identify them and I'll report a bug on ELSE for it, then we can try to solve them together. EDIT: xselect~, xgate~, match~, spead~ rotate~, chance~ all seem to leak. Some of those are because only the outer calloc on sigvec is freed, but the inner callocs are never freed.
I see there's a [playhead] object, I'd love to have it in ELSE so I could use it in camomile ELSE, does it make sense? Or does camomile use another strategy to get that information (via send/receive names maybe?).
Anyway, I wanted to implement something like a playhead/timeline object in ELSE but under Pd's paradigm. For now I'm relying on the new [score] object to do something like that.
Yeah that makes sense, I use the same method as Camomile so that should work fine!
If you want to implement it in vanilla pd you just have to pack the data and put it into [send playhead]. One caveat is that it might have some outputs that are not relevant in vanilla pd. But it would be very nice to have this, because it also means you can design a plugin that uses [playhead] in PlugData standalone or vanilla-pd, and then use it in the DAW with Camomile of PlugData plugin.
i'm just concerned of you having non existing objects in plug data so it would get corrupted if you tried to open the patch in Pd. So I'd like to include [playhead] in ELSE and I think it'd also be useful for ELSE-Camomile. So, how do I do it?
That's true, but the patch will only be very mildly corrupted. Pd-vanilla will probably still load it except for the playhead abstraction, which leads to the same behaviour you'd get in PlugData's standalone, or if you would have access to the abstraction.
Playhead looks like this:
So in pd you can create a fake transport source like this: (playhead_skip should get loadbanged with a zero btw)
Not fully implemented yet, but a decent start. You can then use the playhead like this:
patch:
#N canvas 184 204 933 501 12;
#X obj 294 201 timer;
#X obj 369 143 metro 20;
#X obj 301 399 s playhead;
#X msg 33 302 playing \$1;
#X msg 166 303 recording \$1;
#X obj 168 276 r playhead_skip;
#X floatatom 423 114 5 0 0 0 - - - 0;
#X obj 484 47 loadbang;
#X msg 484 81 20;
#X obj 590 236 inlet;
#X msg 306 304 looping \$1;
#X msg 396 304 edittime \$1;
#X msg 488 303 framerate \$1;
#X msg 590 303 bpm \$1;
#X msg 654 302 lastbar \$1;
#X msg 750 301 timesig \$1;
#X obj 750 232 inlet;
#X text 588 197 Second inlet: tempo;
#X text 743 195 Third inlet: timesig;
#X obj 306 266 r playhead_skip;
#X obj 235 75 inlet;
#X obj 239 164 sel 0 1 bang;
#X text 224 37 First inlet: playing;
#X msg 841 300 position \$1;
#X obj 294 230 s playhead_time;
#X obj 841 264 r playhead_time;
#X obj 158 164 sel bang;
#X connect 0 0 24 0;
#X connect 1 0 0 1;
#X connect 3 0 2 0;
#X connect 4 0 2 0;
#X connect 5 0 4 0;
#X connect 6 0 1 1;
#X connect 7 0 8 0;
#X connect 8 0 6 0;
#X connect 8 0 12 0;
#X connect 9 0 13 0;
#X connect 10 0 2 0;
#X connect 11 0 2 0;
#X connect 12 0 2 0;
#X connect 13 0 2 0;
#X connect 14 0 2 0;
#X connect 15 0 2 0;
#X connect 16 0 15 0;
#X connect 19 0 10 0;
#X connect 19 0 11 0;
#X connect 20 0 21 0;
#X connect 20 0 1 0;
#X connect 20 0 26 0;
#X connect 21 1 0 0;
#X connect 21 2 0 0;
#X connect 23 0 2 0;
#X connect 25 0 23 0;
#X connect 26 1 3 0;
Looks good, I'll see if I can find out what framerate actually means because I sort of guessed here.
I had a small problem: because ELSE binaries are not loaded from files but built into PlugData, using the "else/" prefix won't work, causing many helpfiles to break. For now, I've removed all the "else/" prefixes from the helpfiles, it was really the only solution I could think of. Other than that ELSE compatibility is better, and I've improved the helpfile searching mechanism so it should be all good!
Might not be necessary, I have a packaging script that collects and zips all the documentation, I've just added
find ./Documentation/9.else/ -name '*.pd' -print0 | xargs -0 sed -i "" "s/else\///g"
find ./Documentation/10.cyclone/ -name '*.pd' -print0 | xargs -0 sed -i "" "s/cyclone\///g"
To search and remove "else/" and "cyclone/" in help files. Seems to work perfectly! This also means we don't have to maintain more helpfiles when we want to make changes.
Maybe you should consider renaming the message object, since pd already has a class named "message", defined here:
For now I'll differentiate between them using the amount of args.
Maybe you should consider renaming the message object, since pd already has a class named "message", defined here
but that's internal. Pd also has an internal "text" object, but you also have the native [text] object which is something else
Fair enough, I now check the size of the class which appears to solve this issue as well. The only thing that doesn't work is finding the else/message helpfile, but that's just a filename problem.
[text] has it's help symbol set to "text-object", by doing:
class_sethelpsymbol(text_get_class, gensym("text-object"));
Btw, I've tested [store] and [rec] and they seem to work fine! Did you manage to fix it yourself, or have I accidentally fixed it?
Btw, I've tested [store] and [rec] and they seem to work fine! Did you manage to fix it yourself, or have I accidentally fixed it?
no idea!
M1 Monterey 12.5
I've ran into a number of ELSE GUI patches (so far: [keyboard] and [display]) that don't behave the same as when loaded in pd-vanilla. [display] doesn't seem to display (or output?) anything, and [keyboard] doesn't transpose with 'oct n' messages.
Is this a known bug?
Additionally, I haven't found a way to try to diagnose the problem myself yet, because "cmd-clicking" on certain ELSE objects in PlugData does not open a subpatch (so far it seems to be GUI objects and audio~ objects). However, the same objects loaded in pd-vanilla have a disabled 'Open' dropdown-item, so maybe these patches are not viewable in general?
I'm still pretty novice with puredata, so after checking, I now realize that very few (if any?) of the pd-vanilla objects have 'Open' options / i.e. 'viewable subpatches/abstractions' -- why is this?
very few (if any?) of the pd-vanilla objects have 'Open' options / i.e. 'viewable subpatches/abstractions' -- why is this?
cause they aren't abstractions, many objects in ELSE are though
M1 Monterey 12.5
I've ran into a number of ELSE GUI patches (so far: [keyboard] and [display]) that don't behave the same as when loaded in pd-vanilla. [display] doesn't seem to display (or output?) anything, and [keyboard] doesn't transpose with 'oct n' messages.
Is this a known bug?
Additionally, I haven't found a way to try to diagnose the problem myself yet, because "cmd-clicking" on certain ELSE objects in PlugData does not open a subpatch (so far it seems to be GUI objects and audio~ objects). However, the same objects loaded in pd-vanilla have a disabled 'Open' dropdown-item, so maybe these patches are not viewable in general?
I'm still pretty novice with puredata, so after checking, I now realize that very few (if any?) of the pd-vanilla objects have 'Open' options / i.e. 'viewable subpatches/abstractions' -- why is this?
Display not working is expected, @porres and I have create a new replacement for that, [numbox~], which will be included in the next version of PlugData and ELSE.
The keyboard issue is a bug, I’ll see what I can do about it! Intercepting messages like that and making the GUI respond to it is an area where PlugData is still a bit lacking.