Includes in embedded patch/object

#1

I've discovered that it's possible to add includes to embedded patch/objects by editing the XML of the containing patch.

However, when I do this, and attempt to take the patch Live, I get a fatal error saying the included file can't be found.

I've checked the path relative to the patch file, and it seems correct, using UNIX relative path syntax.

Is this feature supposed to work, and if so, has anyone managed to get it to do so?

I'd make my embedded objects into standalone objects, but I find embedded ones much easier to deal with, so my plan us to leave it to the last minute to export them to the library.

a|x

Axoloti release 1.0.11
#2

check firmware/makefile.patch , in there you will see where the include path is setup.
(actually its probably repeated in the console when you compile the patch, look for -I )

#3

Hi,

thanks for getting back to me.
I'll have a look for that. Should includes inside the XML definition for embedded patch/objects theoretically work though?

a|x

#4

you mean in the include tags? ... as , say like my push.axo?
hmm, theoretically, yes... but....

I suspect if your having issues, its due to trying to use relative include, and the question is then , relative to what? I think normally for objects this would be relative to the object location... but for a patch/object it makes sense to be relative to the patch... and that I guess may not have been coded, but would be relatively straightforward to do in a future release.

I will say though, its arguable that includes don't make much sense for a patch/object.
since these include files could only be shared by other objects in the patch, and heres 'the rub',
one of the main advantages of using embedded objects and patches, is the patch is a single file... if you have an include file thats is now completely broken, as your patch wont compile unless you have the included file too...

that said, not sure at the moment, I can think of a better way to resolve this 'dilemma', though i suspect its related to 'packaging' which Johannes and Ive discussed in the past... but thats a little way off still.

#5

Good points.

Completely understood. However from my point of view, the reason for using embedded objects while developing with the eventual intention of making standalone objects are largely related to current workflow issues with working with the Object Editor and external objects (principally non-recall of Editor window/tab settings when Editor window is closed/opened, and the apparent necessity to delete the object, reload all objects then re-add and reconnect the object whenever changing inlet/outlet configuration. which I find extremely frustrating as I do this often).

It's also useful to keep different versions of the patch file with different versions of the embedded patch/object, to experiment with different approaches.

My workflow is basically this:

  1. Create new patch file. I sometimes save this as a helpfile, in the same directory in the library that the standalone object will live in when exported (so relative paths to include files should work in the same was as with includes for standalone objects)
  2. Find existing object with similar inlet/outlet ports to ones I want, or use the most basic Maths patch as base
  3. Embed object
  4. Develop and test new object code by editing embedded object
  5. Export embedded object to library

a|x

#6

oh, I know why its preferable use embedded objects, Ive a similar workflow too. (except when I put the code externally)

but of course, we should be aiming to improve the non-embedded workflow too, we certainly should not need the delete/reload cycle (actually, reload should not be necessary already, as the save object does it)

of course, as always, so many things to do, so little time :slight_smile:

#7

I'll try using the object editor with a standalone object again (not sure I've done it with the current version), and see if reloading is no longer necessary.

Having to delete and re-add the object is a pain though, especially with objects like these.

Screen Shot 2016-06-23 at 15.23.08.png2836x1892 527 KB

a|x

#8

Of course, and obviously, the time and effort you put into the project is much appreciated.

a|x

#9

yeah, I think the having to delete and add again, is some kind of caching of the original object on the patch... the editor 'attempts' to update it, but I fear probably the patch gives a copy.
then the other 'oddity' is if you do a replace, its supposed to keep same name inlets/outlets, regardless of object type - so again, weird why that doesn't save it.

a random suspicion is this is also why the going live, and editing also causes issue... basically an object 'disappearing' without freeing up is network of connections.

never fear, when we first took the object editor live in this version, we had many more issues, which have been resolved... it was just a bigger undertaking (more side effects) than expected - but we are going in the right direction :slight_smile:

#10

One workaround for the need to delete/recreate an object is this:
use "replace" in the object popup menu, the object selector opens. If you do not select another object first, the selector will be lazy and not replace your object. If you type a space after the name and then delete the space, it will do the replace, and all your connections, parameter values and attributes will be retained.
A dirty trick, I know...

#11

Good to know..
You're right though, is a dirty hack :wink:

a|x

#12

is there a way to add includes from the object editor?

i figured out that one problem when i tried to edit an existing object is that specific header-files are not included, or so. after saving the object to the library and then manually opening the file with a text editor i managed to add the necessary header-files. and then eventually i managed to get it to work. but it's a bit non-obvious to have to do it this way.

also, how to best include header files which are already preset in the factory-library but not in the contribute-library? the problem for me happened when modifying the wave/play fn stereo object. it references streamer.h which is found in among the wave-objects. the simplest fix for me was to just copy that file to the new contrib-path. but this doesn't sound like a good solution. would there be a better way to do this?

many thanks
c

#13

There is currently no clean way to do this.
Duplicating streamer.h will cause conflicts when another object of the wave/play family is present in the same patch.
In a "patch/object", there is no relative search path to look for the include (the object itself does not have a file-path, unless taken from the containing patch, but it could be unsaved too), so only really relevant for library objects.
Using an include is more or less the last resort to avoid replication of large code or data.
I plan to address this, but that will take some time.

#14

thanks johannes.

one option to avoid duplicating the streamer.h would be if the play fn file would have a flag which says it has stopped playing. i needed this so that i can re-trigger the sample to create a loop. here the patch.looping sd card.axp (3.2 KB)
play fn stereo done.axo (2.7 KB)

#15

I will add this feature in the factory library.

#16

Cool. I think I had the same issue when trying to embed the osc/tri. It didnt work, cause it couldnt call up the header/streamer. Had discussion with technobear about. I think this fix will also solve my issue.

#17

Hello @johannes @thetechnobear

I am experiencing some odd behaviour when trying to turn the osc/tri object into an embedded object.

The patch loads fine with the original osc/tri object, but as soon as I turn the object into an embedded object, the patch won't load and I get this message in the log:

Start creating directory on sdcard : /untitled
creating dir: /untitled
Done creating directory
Changing working directory on sdcard : /untitled
Change working directory: /untitled
Done changing working directory

Do this to recreate:
1. Create a new patch
2. Load osc/tri and make the patch live to check it works
3. Embed the osc/tri object and load the patch. Now I get the above error message.

Then I tried to save the patch, which gave same result. It wont load the patch for some reason.

Any idea what this might be?

Here is the osc/tri patch that wont go live on my Macbook 10.10.5.
Osc test 2.axp (2.5 KB)

Btw. I have also noticed a second thing, but this i have not been able to recreate yet and I can tfigure out when it exactly happens. Anyway, sometimes a very complicated patch wont load after doing a "save as". But it doesnt happen everytime.

After "save as" I try to make the patch live and first get a click sound from Axoloti, then it tells me that working directory is changed and the patch wont load. I also get a control fail -4. Non of the sample that is being used are in the patch folder, they are in another folder on the sd-card and the samples are called up using string/index object. So changing the working directory(save as) should not make the samples not load. Dunno of you can make anything of this. But it might be related to the first issue I posted above, something with working directories.

#18

ok, Ive had a look at this...
the cause is that this file uses the blttable.h , which is in the axolotl-factory/object/osc folder, so once embedded it cannot be found.
Im not sure of the best solution ( I don't think it is copying the header file)
there also are two kind of obvious bugs here though:
a) it only gives you the compilation error when you save the patch and then reload it, and go live. it should give you it before you save the patch... Im guessing the 'reason' is before you save the patch and reload it, its not sure where the current directory is.
b) if you copy the offending header file into the same directory as the patch it still doesn't work, for some reason it only works if you copy into the build directory.

not really dug into this more than determining the issue... as Ive visitors at home this week.
and not sure quite how you want to solve this @johannes

#19

Yes, also if you cut the object and paste it back into the patch, even with out saving, it will give you the header error.