Stone

I have a gen~ patch with 3 @gen abstractions in it and each abstraction takes a large number of parameters (216 ea) for control outside the gen~ object. Each of the param objects has a default value as an argument. The gen~ patch takes an extraordinary amount of time (3-5 min) to load/compile when audio is turned on.

I suspected building a standalone would help as I assumed it would pre-compile, but no difference.

Is there another strategy to load parameter values that might speed up the compile time?

Any suggestions would be greatly appreciated.

Is there another strategy to load parameter values that might speed up the compile time? 

Hello,
I have a gen~ patch with 3 @gen abstractions in it and each abstraction takes a large number of parameters (216 ea) for control outsi

slow-loading-of-gen~-patch

Yes, what you can do is put the param values in a msp buffer using pokes with the peek~ object, then read them into gen with peeks inside gen.

Thank you, Ernest. I have implemented your method and it loads much faster.

Could you shed a light on your method of speeding the gen patchers loading time? I have the same issue, however I don't completely understand how to implement such method in my current environment.

I have a codebox with Params and codebox without Params with exactly the same functionality. Each gen patcher loading time is the same, so I suspect it has nothing to do with parameters.

Could you show a patch example of what do you mean by evoking parameters with "peeks inside gen"?

I think Ernest was responding to Stone's situation of having 216 params in a gen~ patcher -- which is indeed a lot! To share that amount of data with gen~ it would be more efficient to use a shared buffer~ object. Outside gen~, write values to the buffer~ using e.g. a MaxMSP peek~ object. Inside gen~, read from the buffer using the peek object. Each sample in the buffer would replace a param. It's not as friendly as using messages and param objects, but is more efficient when needing to send a large amount of data from Max to gen~.

I'm not sure if this would help in your case -- I saw your other message, and I wonder what is in your patcher that would make it take several minutes(!) to load. Most gen~ patchers load very quickly.

Do you have a codebox that calls require to load in more functions? Is what you are loading quite large? If so, can you paste only the code you need into the codebox, rather than the entire library? Similarly, is there any code in the gen patchers that is not actually being used, which could be deleted? Even if objects or functions are not hooked up, gen~ still needs to parse the contents to find that out, and parsing is almost as expensive as compiling.

Could you break up your gen patchers into smaller fragments, rather than putting everything into one huge gen~ patcher? The efficiency benefits of using gen~ can disappear if the patchers get very large -- that is, the efficiency wouldn't be much different if they were spread over multiple gen~ objects. That might also help loading times.

Do you use a lot of small data or delay objects? If so, would it be possible to re-use the same data or delay to achieve the same result?

I think Ernest was responding to Stone's situation of having 216 params in a gen~ patcher -- which is indeed a lot! To share that amount of data with gen~ it would be more efficient to use a shared buffer~ object. Outside gen~, write values to the buffer~ using e.g. a MaxMSP peek~ object. Inside gen~, read from the buffer using the peek object. Each sample in the buffer would replace a param. It's not as friendly as using messages and param objects, but is more efficient when needing to send a large amount of data from Max to gen~. 

I'm not sure if this would help in your case -- I saw your other message, and I wonder what is in your patcher that would make it take several minutes(!) to load. Most gen~ patchers load very quickly.  

Do you have a codebox that calls require to load in more functions? Is what you are loading quite large? If so, can you paste only the code you need into the codebox, rather than the entire library? Similarly, is there any code in the gen patchers that is not actually being used, which could be deleted? Even if objects or functions are not hooked up, gen~ still needs to parse the contents to find that out, and parsing is almost as expensive as compiling. 

Could you break up your gen patchers into smaller fragments, rather than putting everything into one huge gen~ patcher? The efficiency benefits of using gen~ can disappear if the patchers get very large -- that is, the efficiency wouldn't be much different if they were spread over multiple gen~ objects. That might also help loading times. 

Do you use a lot of small data or delay objects? If so, would it be possible to re-use the same data or delay to achieve the same result? 

Thank you for your response. First of all I would like to clear up my purpose of using Gen~ in a first place. At the beginning I made an algorithm with completely native Max/MSP objects. Then I decided to speed up things up to the discretization frequency and used the sample-precise gen~ object. I rewrote all gen objects in a one codebox for simplicity in handling and exporting. Now each gen codebox is about 6000 lines of code, which is large for gen in my opinion. I tripple checked everything and sure that there is no orphanes, which parser may use in compiling process and which slows the things down.

I use wavetables for waveshaping and synchronization functions, so yes I use data with pretty large size of up to 262144 samples. I also use up to 9 delay modules with 12 taps each with a large buffer size of samplerate * 3.

This is what consumes most of the loading time. I also have from 14 to 17 function declarations depending on gen patcher version.

The reason I use all the gen~ inside one patch is evident. I want a simple way to switch between the code, while testing it. So, for example, I use toggles to switch between different bpatchers of different gen code versions.

I spent last 4 years polishing the project and think I made any performance improvement possible including switching from buffer~ to data and eliminating using history modules inside gen~ for that data modules. I think the improvement should come from Cycling's side. I'm personally don't whish to change wavetables on formulas instead as I want to use the lookup function inside codebox.

What I think of: is there any possibility to make patchers not hanging on Windows while parsing and compiling gen~ code? Is there any possibility to implement gen loading status bar or even creating custom splash screens for standalones?

Thank you for your response. First of all I would like to clear up my purpose of using Gen~ in a first place. At the beginning I made an algorithm with completely native Max/MSP objects. Then I decided to speed up things up to the discretization frequency and used the sample-precise gen~ object. I rewrote all gen objects in a one codebox for simplicity in handling and exporting.  Now each gen codebox is about 6000 lines of code, which is large for gen in my opinion. I tripple checked everything and sure that there is no orphanes, which parser may use in compiling process and which slows the things down.

I use wavetables for waveshaping and synchronization functions, so yes I use data with pretty large size of up to 262144 samples. I also use up to 9 delay modules with 12 taps each with a large buffer size of samplerate * 3.
This is what consumes most of the loading time. I also have from 14 to 17 function declarations depending on gen patcher version. 

What I think of: is there any possibility to make patchers not hanging on Windows while parsing and compiling gen~ code? Is there any possibility to implement gen loading status bar or even creating custom splash screens for standalones? 

Slow loading of gen~ patch