bach.mxo inclusion in project?

[stkr]

hi.

i realise life is easier these days with no explicit frameworks and so on, but should i include the [bach.mxo] extension in a project where i have a handful of bach.* externals?

it is a .amxd, with one [bach.ratnum] and a few others (from [bach.sieve] abstraction). my device is freezing fine those things, but should i include the extension as well for it to work properly on other machines?

also, .amxd projects seem to include other architectures fine for the externals, but is has difficulty doing this with the extension.

any ideas?

thanks.

[danieleghisi]

Hi stkr

Yes, bach.mxo should be included. I'm no expert in amxd files, but for building collective/applications, such file is automatically included.

YET - IMPORTANT: If you installed latest version (0.7.2) there's also also the bach.initpargs.mxo external to be included. This is tricky, since it is not in the extensions folder, but in the externals one. Next release (online in a couple of weeks) will solve this issue (only the bach.mxo extension, which should be by the way automatically included when creating a collective/application)

Tell us if everything works!

d

[danieleghisi]

Correction: since the use of packages, bach.mxo is NO LONGER included automatically when you create an app.
This is sad, and I don't like it, but we can't do much about it. Cycling should include all packages extensions, when needed...

For the time being you have to include bach.mxo by hand...

[stkr]

danielle,
many many thanks for all this info. bach.initpargs - i had no idea.

however, to report the story:
- firstly, .amxd is the same as .maxproj, so the following is bad news all round
- some background:
- .amxd & .maxproj automatically include the opposite architecture's externals if they are in the search path, which is working fine with the bach library. however, this is one of the reasons your package annoys me - there is no need to separate the osx and windows 32 & 64 downloads - i have to download all three just so i can extract the other externals to have them sitting in my library to take advantage of the .amxd & .maxproj auto include feature.
- auto include works for externals in the externals folder (i am on osx, i have the win32 and 64 externals in their own folders in the osx externals folder of the package). however, it does not work for the extensions folder. for example, if i include bach.mxo and create local project version, when 'freezing', the win32 & 64 extensions are not included (unlike all externals which do successfully auto include other architectures).
- it seems the only way to auto include bach.mxe & mxe64 with bach.mxo is to temporarily move all the bach.mxo/e/e64 extensions to the externals folder in the package, then reinclude them and then refreeze. then move them back in correct package locations afterwards.

however, it would be nice if this workaround solved the problem, but it does not.
- successfully including everything as above does work for the following externals (they are recognised and operate properly):
bach.reg, portal, initpargs, args, iter, collect, ratnum
but NOT any of the following:
bach.==, !=, <, <=, >=, >
these simply refuse to instantiate in the self contained project even though all the correct files are there.

it seems .amxd & .maxproj have problems with the whole 'extensions' thing. my research has not gone any further at this stage, sorry. however, i will report all this to jeremy @cycling.

i actually just wanted an easy and quick way to take advantage of bach.ratnum & bach.sieve & bach.reg in a project i am in the middle of, as my brain could not handle how to efficiently represent rational numbers related to transport without bach. if anyone knows a good max-only way of doing that, please let me know!

thanks,
stkr.

[danieleghisi]

Hi stkr, thanks for the feedback. I'll answer below.

- firstly, .amxd is the same as .maxproj, so the following is bad news all round

If this is the case, I already forecast troubles. Max projects are a great things, but Cycling has not really helped going through third party libraries.
So a lot of stuff, instead of simplifying life, drives people crazy. The very same thing is true for standalone applications and packages.
I've notified cycling about this myself, but if you can send also an email yourself; that's always useful I guess to stress the importance of the thing. I hope they're going to change it in the next few versions, otherwise packages are only usable for straightforward stuff... (once you have extensions or inits... it's more troublesome!).

- .amxd & .maxproj automatically include the opposite architecture's externals if they are in the search path, which is working fine with the bach library. however, this is one of the reasons your package annoys me - there is no need to separate the osx and windows 32 & 64 downloads - i have to download all three just so i can extract the other externals to have them sitting in my library to take advantage of the .amxd & .maxproj auto include feature.

I understand your point, and you might be right. Andrea is better placed than me to answer this kind of questions.
I myself think that the macintosh bach external folder alone is (uncompressed) 76Mb. Windows externals are a bit smaller. Yet, I'm not sure it is reasonable to have people always download three times the things they need. On the other hand, I see your point. I'll talk about this with Andrea.

- auto include works for externals in the externals folder (i am on osx, i have the win32 and 64 externals in their own folders in the osx externals folder of the package). however, it does not work for the extensions folder. for example, if i include bach.mxo and create local project version, when 'freezing', the win32 & 64 extensions are not included (unlike all externals which do successfully auto include other architectures).

That is true. But - sorry about that - this is a cycling'74 issue (of the kind I told you above). We can't do anything at all about this!
Apparently only if you put extensions in the Cycling'74/extensions folder these are automatically include. This is cumbersome, since it cuts away all third party libraries, as I said. No solution, sorry – unless one drops the idea of packages, and comes back to "hard installing" bach in the cycling '74 folder. Possible. That'll solve all the issues. Yet this is somehow stupid... packages are so handy! The best should be to improve them... Hope C74 will help!

- it seems the only way to auto include bach.mxe & mxe64 with bach.mxo is to temporarily move all the bach.mxo/e/e64 extensions to the externals folder in the package, then reinclude them and then refreeze. then move them back in correct package locations afterwards.

Yes. Also, for standalone app, you can also include bach.mxo manually with "Include file...".

Again: why don't you manually install bach "Max5-style"? It's a step back (with respect to packages), I know... If you put all extensions in Cycling '74/extensions, all inits in Cycling '74/inits, you create a bach subfolder (say Cycling '74/bach) and you put all abstractions and externals, and so on. This will solve all the issue.

- however, it would be nice if this workaround solved the problem, but it does not.
- successfully including everything as above does work for the following externals (they are recognised and operate properly):
bach.reg, portal, initpargs, args, iter, collect, ratnum
but NOT any of the following:
bach.==, !=, <, <=, >=, >
these simply refuse to instantiate in the self contained project even though all the correct files are there.

This problem is the "init" problem.
Just move anything in the bach init folder inside Cycling '74/init/ folder, and everything should work!
Again: this is a cycling '74 problem: package init files are not kept into account. Which makes inclusion of complex packages extremely cumbersome.
But if you do as I did, you should work it out...

i actually just wanted an easy and quick way to take advantage of bach.ratnum & bach.sieve & bach.reg in a project i am in the middle of, as my brain could not handle how to efficiently represent rational numbers related to transport without bach. if anyone knows a good max-only way of doing that, please let me know!

Yes, try to "hard install" bach in the cycling '74 folder, "Max5-style": everything should work flawlessly.
Namely, the very important part you need is to put the init files inside Cycling '74/init, and the extensions in Cycling '74/extensions.

(Please remember that you installed bach this way, should you upgrade it! Indeed, if not, you might have conflicts in the future releases – when hopefully Cycling will have fixed the package support)

Let me know if it works

[stkr]

he danielle, thanks.

indeed i realised after that it would be the init file i needed.

i think projects and packages are the way forward. they are just a bit 'young' and annoying and don't really work properly at the moment.

i've contacted cycling.

thanks for all the help.

[danieleghisi]

Hi stkr,

I agree. Projects and packages are great stuff, just a bit young, as you say.
They might really be a game changer in patch and library sharing.

[danieleghisi]

- .amxd & .maxproj automatically include the opposite architecture's externals if they are in the search path, which is working fine with the bach library. however, this is one of the reasons your package annoys me - there is no need to separate the osx and windows 32 & 64 downloads - i have to download all three just so i can extract the other externals to have them sitting in my library to take advantage of the .amxd & .maxproj auto include feature.

Little update: we were about to follow your advice and to make a single package containing all Mac, Win32 and Win64 architectures, for the forthcoming bach 0.7.3 release.

It turns out that there's what appears to be a bug in Max, which sends a red message on Mac if you have Win64 files (.mxe64) in the extensions folders (although everything works fine with the externals).
Out of curiosuty, don't you have any? If you have bach.mxe64 in the bach extensions folder and you open Max (64 bit), don't you have an annoying error red message at startup?

Due to this we have decided that for the time being we stick with separate Mac and Win versions. But we really hope it's just temporary, until Max has in turn solved this issue.

Thanks for the tip,
d

[joelgtaylor]

Hello!
Is this problem with projects and packages still a current problem, now in 2017, under Max 7.3.4?
I ask because I am contemplating beginning a complex project that uses the Bach package and would like to anticipate this kind of issue instead of having it bite me towards the end of the project when I start trying to put together an application that runs on both Win and MacOS X platforms.

Thanks for your time and for all the work you have done on making this package so powerful and elegant. I'm just beginning to make use of it and it promises to be a great boon to my personal music work with Max, as well as for programming applications. Brava!

-Joel