Does anyone have tips on memory usage with chops .. I've tried time slice and this doesn't really allow for most of the EQ and Oscillation processes I'm using.

I understand if Houdini isn't made for this stuff, and I certainly don't need it to perform like an audio program, but the memory allocation crashing seems to be pretty unpredictable and based on when I cook stuff, where the display flags are, and if audio is turned on etc etc.

For instance, if I simply push the bypass flag on and off with my full dig asset, it will surely crash if I have lots of notes coming into it. If I connect notes without audio or display flag, then pipe into a null, then turn audio on for the null, normally no crash. Weird.

Another somewhat related question … does Houdini put the full CHOP into memory similar to a raster image before it does the next operation (if time slice is turned off anyway) or is it buffering somehow.

I've considered another approach as well … would I get a significant performance boost by re-doing my synthesiser in VEX (currently it is a chain of around 200 chops)?

Right now I can get around 2 min of one tone or with multiple tones, around 40 notes of around 1 sec a piece spread through time (essentailly two minutes of stuff, 44100). Would anyone take a guess as to wether this was a Houdini limitation or a computational limitation?

If it's a computational limitation should I rework the synth in VEX?

Has anyone tried similar things (creating synthesisers in Houdini)

andrewlowell
Does Houdini put the full CHOP into memory similar to a raster image before it does the next operation (if time slice is turned off anyway) or is it buffering somehow.

It keeps all the raw data in memory. I think almost all CHOPs keep the copy of the data around for interactive purposes. So take however much memory your audio is taking, multiply by the number of CHOPs you have and that's how much memory is used by default (with time slice off).

In the parameters, there's an “Unload” parameter in the Common tab that you can turn on. This will free the memory from the CHOP when it's no longer needed. However, if you then manipulate any parameters on any of its outputs, the CHOP will need to recook from scratch.

actually that is probably exactly what I was looking for … thanks!

has anyone encountered any differences between how CHOP DA's act with unload / vs. not unload? I'm getting some weird stuff going on when I say “unload” in the lowly-nested chop DA's.

Got a simple way to reproduce?

well, not simple it will take some time to put together … maybe I'll upload tomorrow. In theory should there be a difference?

Also, if I have let's say, chop DA's inside of chop DA's, … or networks inside of networks … will turning on “unload” on the top DA cause the other DA's inside of it to also be unloaded when they are done. It's not acting like it, it's acting like the sub stuff is being stored inside of memory even though the top one says unload. Should it be this way?

Each CHOP has its own copy of the cooked data, including the SubNet CHOP. I think the SubNet CHOP just makes a copy of the data from the specified child. So all the unload parameters are independent. I'm just guessing here though, I haven't actually checked.

ok, here's a working example of the unload acting strange. This digital asset works fine when the unload's inside of it are turned off, however, when they are turned on, it output's no channels.

To get it to output the channels, go inside the asset, and toggle on “unload” or “bypass” on and off for “compute lookup.” … which is where the action pretty much happens.

It turns out to be a bug that has nothing to do with CHOP HDAs. You ran into a bug with the unload parameter and your particular network setup. For now, I think the easiest workaround is to turn off unloading on the countBeats chop.

well, I went through all my assets and was able to turn on most of the unloads (most by trial and error). So, I guess the workflow would be to keep them all on in development, then turn them off until something breaks.

Any general clue what is safe to turn off and what isn't? In any event thanks for taking the time to look that over, I'm glad to know it was a bug and not me

It's hard to explain. You can check out the attached .hip file which reproduces the problem in the simplest way possible. BTW, tomorrow's 8.1 build should have this bug fixed (8.1.842).

awsome, thanks for taking such an interest, and to you and whoever else is responsible for fixing the problem .. sidefx rocks