M4L crashes in Eurorack control patch
This is a bit of a specialist problem, but just in case anyone's got any bright ideas...
I've got a pretty neat scenario going on, or at least it should be. I'm running 8 oscillators in a Eurorack synth. Each of them is routed into Live and then out to one of 8 speakers (the interface is an RME Fireface UC). They're playing various harmonics - the voltages to produce these are generated by M4L plugins and routed out to the 5v/o inputs of the oscillators (via Expert Sleepers plugins and modules). The plugins are also regulating the tuning - the pitch coming from the oscillators is tracked using sigmund~ objects and compared with what's expected, and the 5v/o signals tweaked accordingly. It works a treat and sounds great (though I do say so), BUT it consistently crashes Live. The pattern is quite strange - it can take anything between 5 minutes and over an hour to crash, and it doesn't seem to make much difference how much activity is going on (ie how much the harmonics are changing). To me it seems a bit like a memory leak or something. The DSP meter in Live is reading around 15 percent (that's with a few effects plugins too) - I know this is notoriously innacurate, but running a similar patch (equivalent to one plugin) in Max gives a CPU load of just 1 percent.
Each oscillator requires one audio channel which has a simple pitch-detector plugin on it:
.. and then an instrument track with the harmonics/tuning patch on it:
(data is sent between the plugins using send/receive/forward)
So that's 16 plugin instances in all and a whole bunch of tracks in Live.
I've tried a whole bunch of ways of doing this. All the constituent parts tend to work without a crash, but it's only once everything is joined up that the crashes start. I've monitored the data going on as much as I can and there don't seem to be any divide by zeros, infinity or nans. I've also tried all sorts of ways of smoothing/thinning/slowing down the data, which don't seem to make any difference.
I appreciate this is all a bit opaque, but if anyone has any ideas or inklings as to what might be causing these crashes I'd be very very grateful!
Thanks
oh i looked at other thread where you have it working fine in max alone. sorry ignore this because that's where it's not working for me....
you have to make an aggregate device for expert sleepers, right?
i wonder if something is up there because i've been having problems with aggregate device too in combination with rme ufx... haven't tried es, but a few different interfaces, none work. max will get slow to turn on/off dac and then crash.
(was thinking maybe i'd have to get es...!)
sending cv signal out, getting audio in, cv i/o as own devices in separate program instances doesn't seem to crash.
Responding to the original post.
Don't know if you ever solved this issue, but with Live 9 / Max7 in Nov 2018, I'm seeing what is likely the same issue: I'm sending MIDI data from Sigmund~ (and other objects) across tracks (MIDI and Audio) using send/receive/forward. Often, and seemingly at random, Live hangs abruptly, appearing normal, but can only be terminated by the Finder's Force Quit option.
Since we both are using Sigmund~, this may be implicated. But I also have tended to favor the hypothesis that it's related to send/receive, which are sort of going behind Live's back, so to speak, since they are not using Live's standard signal routing (my sense is that there may be a timing mismatch between audio rate processing and control rate processing, though that is only speculation).
If you get this message, please let me know if you ever resolved the issue (and I will do so as well). The need to send MIDI across tracks is central to the architecture I require in Live/M4L.