doesn't seem like very many signals to use up cpu, but the first thing i'd do is increase vector size and the i/o buffer size, which you can adjust in the dsp status window-- maybe reduce sample rate too if it is greater than 48000; what speed computer are you using? make sure it's above the minimum specs for msp. another thing you can do is put the control signal generators in a poly~ and reduce the sample rate of the poly~ (see the poly~ help file for how to do that)

As Terry suggested, down-sample your LFOs and envelopes wherever possible using poly~. Be sure to turn off the resampling filters in poly~, because they can eat up quite a bit of CPU, and they will also change the output range of your LFOs. (There was a thread on this a few weeks ago)

Also, how are you connecting things? If you need a lot of possibilities, but not a lot of connections, send~ and receive~ are the way to go since you can re-route them via the "set" message. If you need a lot of connections and possibilitiesm you might look at matrix~.

I posted a modular synth project recently. It uses send~ and receive~, since I needed to be able to interconnect a ton of things, but most connections were not made. You could also wrap your send~ or receive~ objects in a poly~ to turn them off when not needed.

Here's something I used about 4 years ago - It worked rather well for what I was doing, but this is for control signals only, so it may be too lo-res for your needs... anyway, I figured I'd post it.

It uses jitter matrices and jit.cellblock to handle a 16*24 matrix with adjustable levels. Just looking at it now reveals things that could be tweaked, but hey... c'est la vie.

when building such a mod matrix on the audio domain, i would start with the mixer part, i.e. *~ and +~es, where the different controls meet.

At this point I usually chip in to mention matrixctrl in dial mode as a way of efficiently fitting a lot of controls into a small space. It's not very well documented, in fact I don't think it's even mentioned in the .help patch, but you can give matrix~ a third argument and use matrixctrls with more than two states to make a matrix that acts like a mixer rather than a simple switcher. It wont do much for CPU economy, (though you can always down-sample, as suggested above), but by combining the switching and level controls into one, you can save a lot of space and simplify operation. You do have to make your own graphics, or find some, but it's worth the effort; fwiw, I think sliders work better than dials, as it's easier to orientate yourself when using a big matrix, Cheers Roger

a big thank you to all of you! @terry Im workin on a brand new custom mbp with a 2.5 i7 quad and 8 gb ram and a hackintosh i7 overclocked 3.8ghz and 8gb. so that should be ok. and its not the problem that the synth or the mod matrix needs the whole power but, it`s gonna be a max4live device and should run together nicely with more tracks, other instruments and fx. so i need the cheapest way possible.

@peter: wow! your synth is amazing (as all your other stuff! you might not know, but i already learned a lot from you). i would love to study the whole structure, but my time is very limited and your patch is so complex :-) at the moment im using a modified version of the jsui dragndrop example, matrix~ and osc-routings. the patch is not for me only and its definitlely needed that even unexperienced users should understand it (@wetterberg: thats the reason why i cant take your way, but very interesting).

@roger: thanks, i know. i already was thinking about making an extra float window with a matrixctrl in dial mode.

one more question: is it possible to have a downsampled poly~ inside an upsampled poly~? (does that even make sense?) and i thought it would be the best to send the modulations only to the voices which are active. but how how do i manage the poly~ messages for the poly inside the poly?

sorry for my english, i hope that all makes any sense for you :-)

cheers andreas

Hi Andreas, as per matrix~, Roger is right about the third argument. I've been using that for years (in the G4 era, it was blazingly fast since it was Altivec-optimized) and it works very well.

here's an object of mine that turns matrix~ into a mixer with volume and panning. It also does mute and solo (IIRC).

For the upsampling, you can do it, but I'm curious as to the reason for doing so. (FM?)

BTW, in my opinion, a de-centralized system (a la send~ and receive~) is way easier to implement if you're good with abstractions. I built the modular synth in about two weeks in my spare time. The send~ architecture in that patch made everything fall into place.

thanks peter, as i wrote: i know about that possibility with matrix~ and i already used your tool in some other patches i created (very nice!)

i don`t want to upsample my modulators i want to downsample them, but some targets are in an upsampled poly~. so the question was: what to do then? (poly~inside poly~?) or should i make the modulations completely outside?

thanks in advance andreas

edit:

it must be inside the poly because all the paramters are modulatable with poly-At too, which also should be able to be the first source if there are more.

you can have nested poly~ objects, and I assume you can have an upsampled poly~ within a downsampled one-- if I were you I'd patch a test to see if it works