sigmund~ efficiency?
Anyone have any hints as to how to streamline the processor efficiency of the sigmund~ object? I'm using 8 of them simultaneously, and it's giving me some problems. Although the CPU utilisation given in the Audio Status window is only around 4 or 5 percent, according to the (Mac) Activity Monitor it varies between 90 and 110 percent. If I disable the sigmund~ objects that goes down to 30 or lower.
The object as I'm currently using it is [sigmund~ @npts 4096 pitch] - I need the @npts 4096 (I think) because the frequencies I'm tracking can go quite low (somewhere between 30 and 40Hz) - this is also why I'm using sigmund~ rather than any of the other pitch tracking objects, none of which I can get to go that low.
I can't find much documentation of the sigmund~ attributes though, and I'm wonder if tweaking any of them might make it more efficient. I'd also welcome any general Max tweaks anyone thinks might help - Parallel processing and overdrive are on, and I've messed about with vector sizes, but currently have them both at 64 to reduce latency.
I'm still using Max 6.1.8 for this, and the 32 bit version of the external.
Any bright ideas very gratefully received!
Increasing the size would reduce the process power (as far as I know) as it doesn't have to process chunks as often (like raising the vector size in the settings).
64 is pretty tight for vector size/IO unless you need percussion-ish tightness. You're going to inherit latency from such a high npts setting on sigmund anyways, so vector size won't help you there.
That being said I've not found sigmund to be too expensive, so it might be worth trying other variables. Have you tried the new 64bit version?
Thanks Rodrigo, that's very helpful. Yes, I suppose it makes sense that the large npts setting would actually reduce the cpu - without thinking it through I'd assumed the opposite.
I did squeeze the vector sizes down by a process of experiment - bigger than this and the timing does sound very loose (yes, presumably due to the high npts) and it did seem to make a difference. But maybe I'll have to compromise on this. I'm (still) slightly unsure as to the two vectors - although I've read up on what they are/do I'm still not sure of the impact each might make respectively.
Maybe I need to try the 64-bit version - it did occur to me, although I'm currently running 32-bit Max. Interestingly, when I ran the patch in Max7 (I'm currently transitioning between the two, probably rather slower than I should be) it seemed to run a lot less efficiently - maybe I should try that again.
The vector/IO stuff is confusing but I generally just think of it as trading off latency for in-efficiency. When I'm doing drum/percussion oriented things I'll go with 64/64, but most other times I'll go 128/64, and don't really "feel" the latency.
And for tracking low notes, you're in a physical trade-off game too. The lower the notes you want to track, the higher your latency has to be (in order to capture a full cycle of the waveform).
Out of curiosity, what are you tracking that you need so many of them and so low?
I think fzero~ will go that low.
Thanks again Rodrigo. I had experimented a lot with the vectors, but with your inspiration I've gone back to 128/64 and although I can feel the latency a little, it's a reasonable compromise (it still doesn't completely solve my problem, but it helps!).
I've tried the 64-bit version of sigmund~ now (the v.0.07 one) - it seems to make surprisingly little difference to this, although if anything it makes it slightly worse. Was well worth investigating anyway - quite apart from anything else it comes with a helpfile I'd not seen before which will really help me tweak those parameters!
What I'm doing is tracking 8 analogue (Euro) oscillators - I'm controlling them using CV voltages generated by Max to get harmonics and other pure ratios rather than tempered scales, and using the data from the 8 sigmund objects to adjust the CV voltages to keep them perfectly in tune. It works a treat, but the heavy CPU load makes Live, which I'm running at the same time, to hiccup. I originally did all this in Max for Live, but that caused crashes rather than hiccups. Perhaps I should abandon Live altogether, but there's still quite a bit going on in there which would be hard to replicate.
Thanks Mzed. I've been working on this for a while and I've tried every pitch tracking method I can think of - fiddle/pitch/analyser, various descriptors object, fzero and even a roll-your-own zero crossing method. sigmund is the only one that gave me reliable/stable enough data to make the tuning work - if it wobbles around too much it goes hilariously all over the place chasing its tail. I might look at fzero again just for the very low frequencies though - thanks for the nudge.
Ah I see. Is the drift that bad that they need to be massaged constantly that way?
If you're tuning pure intervals it might be worth trying to tune the composite via beating, rather than individual oscs.
Thinking a strobe tuner: https://en.wikipedia.org/wiki/Electronic_tuner#Strobe_tuner
So maybe comparing each external osc with an internal osc of the desired pitch and getting some amplitude/beating tracking going on.
This would also allow you to crank the vector size back down to 64 for minimal latency too.
The drift isn't really that bad, but I found with pure harmonic intervals - especially in the higher harmonics - they really need to be spot on in tune or they're a bit painful. I was spending more time tuning than playing.. I don't massage the tuning constantly, only at intervals or when the cv pitch changes. They do sound really great perfectly in tune, and I'm working towards FM between them, where the tuning will make a huge difference.
The strobe tuner is a great idea - thanks for that. I'll give that some thought!
I’m returning to this after a little while - had to deal with some other stuff for the last couple of weeks, but have been thinking about this from time to time.
I can’t quite think how one might approach building a strobe tuner, even though at first sight it might seem a trivial problem. Setting up an oscillator for comparison, and producing the beats is trivial - the stumbling block for me is timing them. The strobing is entirely smooth, so there are no obvious onsets other events to detect. I guess some way of timing periods between maximum and minimum intensity would be the way to go, but I’m not immediately thinking how to do that. Feeling a bit stupid - does anyone have any ideas?
Yeah I was in the same boat, otherwise I would have posted a simple example patch.
I presume by tracking changes in amplitude, and since it's a relatively known variation (ie the beating will be periodic), that should simplify things too.
But that being said, I too wonder about ideas for this.