Holiday notice: Cycling '74 will be closed Monday, October 9th. Manual authorization, support cases, and manual order processing will be delayed.
Dynamicdsp~ in standalone or collective
Jan 24 2012 | 12:42 pm
I have a largish project that uses Alex Harker's dynamicdsp~ objects, which works just fine in the Max environment, but as soon as i try to make a collective or standalone, it falls apart.
It looks like the process of compiling/linking/whatever (don't shoot if I'm using the wrong language, I'm not a programmer) is not happening for this object, because it shows as a bogus object in mxf/app, despite the fact that the Max windows says "Copying External dynamicdsp~". Can anyone confirm this?
Max 5.1.9. btw.
Further to the whole collective/standalone issue, is it me, or is this a really problematic area with Max? A lot of people seem to have issues with it.
As well as the above I'm finding other objects which are not making it into standalone versions, despite messages posted in the Max window saying they are being included.
I'm using the workaround posted in this thread (https://cycling74.com/forums/a-workaround-path-to-standalone-from-within-standalone) to make the search paths, and again it works fine for locating a folder full of bpatchers in all three cases, but then when you load the bpatchers there are often objects missing in the standalone version.
Is there anything special I need to do for bpatchers - I've tried including everything in the build script, but it's still flakey,
cheers
Roger
Cheers
Roger
- Jan 24 2012 | 8:49 pmyou have to add them inside the contents of your app manually after the build. it very simple. some big distros like ftm and jamoma and taptools have scripts which do this for you. for the rest of us there is drag and drop. does it help? hope so.
- Jan 24 2012 | 10:06 pmBingo! Thanks.Should have remembered that from the old Pluggo days. How would that work for a collective though? cheers Roger
- Jan 25 2012 | 11:45 amOk forget collectives, a working app is better than nothing. Still getting the odd missing item, but the dynamicdsp~ patches are now working.Got this, though:"(mxj) Unable to find max.jar! mxj is rendered powerless in its absence."Where do I put that? Sorry to be so needy, but I'm pushed for time, Cheers Roger
- Jan 25 2012 | 1:37 pmYou should copy by hand the classes and lib folders, and the max.java.config.txt file into the Resources folder in your app. Those files are located in the Cycling '74/java folder.If you want the smallest size for your app, most of the stuff in those folders can be removed, just keep the one you need.p
- Jan 25 2012 | 1:58 pmExcellent - thanks! Cheers Roger
- Jan 26 2012 | 9:06 amHi Roger,I think the problem here relates to the dual-bundling of the external, where the outer .mxo is actually just a loader for the inner ones, which are specific to max4 or max5 (the object is quite old now). I think my convolution objects suffer the same issue. Good to know that adding manually solves the problem (out of interest I assume you only need to do it for dynamicdsp~ and not dynamic.in~ etc. ?). I could build them only for max5 onwards which would probably solve the issue, but at the time of release I was still trying to avoid having different public and private builds, and every so often I need to reopen stuff in max4....Alex
- Jan 26 2012 | 10:19 am@alex, cheeky questions: any news on possible windows builds? and: any news on Max6 64-bit signal path builds?
- Jan 26 2012 | 10:42 am@pidI have windows builds here which have recently been used elsewhere without any known issues. I have one issue I'd like to resolve and then I think I am ready to release for now at least. I'll probably release an update for the mac builds to deal with a couple of bug fixes at the same time. Both sets will be built from the same source. If you haven't seen anything in two weeks time please hassle me about it and I've get on to releasing.No concrete news on 64bit builds, although the convolution objects will not go 64bit internally, as the memory requirements/CPU overhead is not worth it. Basically I'll tag my own 32bit wrapper onto them. Unfortunately all other objects need a new perform routine, which is at least 40 unique routines to write. I just don't have time right now, but it is on my to do list...In terms of dynamicdsp~ and 64bit, patches internally run at 64bit, it is only when you go in/out of the object that it will be truncated for 32bit, so it is not quite so bleak....
- Jan 26 2012 | 6:16 pmHi Alex, Just wanted to say a huge thanks for these objects, and yes, I can confirm that manually adding dynamicdsp~ alone was enough. Handing this project in tomorrow - can finally have a proper look at Max 6 now :) Cheers RogerP.S. I still use Max 4 from time to time too.
