Send/Return

I am making a series of drum synthesis custom units, and would love to add some surface level Send/Return type effects that control things like distortion, reverb, etc. Elektron style I guess. I ran into the problem that these effects were somehow too destructive when I add them somewhere in that chain, so it would be nice that those controls actually affect the wet/dry mix instead of a parameter in the reverb or distortion etc. unit. Is that possible, in one custom unit?

maybe setting up some FX in global chains might help you out.
you can set them all wet and mix them back into your custom units?

Oh I see. I haven’t played much with global chains. So they can be part of the custom unit then?
@mopoco I just edited my question cause apparently I wrote “part of the global unit” instead of “custom unit”. Anyway, yes will check out the Wiki :slight_smile:

the wiki article should answer some of your upcoming questions:
http://wiki.orthogonaldevices.com/index.php/ER-301/Global_Chains
i wonder whether the best solution for your drumsynth units would be to
set them up as global chains as well. this way you’ll have seperate
outputs you can then mix in to your (global) fx chains as well as into your main (outgoing) chains…
let us know how this works.

1 Like

I think I also might benefit from watching @rbeny 's Ultraviolet custom unit, since he’s done what I was trying to figure out with sample loopers:

You can’t include a global chain inside your custom unit. You can reference a global’s output in your CU but can’t save the actual global chain as part of the CU. You could save the machine state as a quick save which could be shared if desired though.

I think this is one of the places where middle layer patching starts to shine, since you do get access to a unit’s input, wherever it happens to be inserted, and can route it more arbitrarily internally within the unit. Pretty sure you can also tap the signal at any place in the path, really. But I’m still learning the middle layer so not 100% sure.

The approach used in Ultraviolet should work. I think the disadvantage is that you’re adding overhead with the sample player and recorder which are really only being used for signal routing.

That was indeed my first concern.

I’m following the middle layer thread with interest but also some distance because I don’t want to loose myself too much in the technical aspects. But you are probably right.

1 Like

Would be great if we could unlock the internal signal routing (at least in a custom unit) with the middle layer.

The sample player/looper workaround doesn’t take up too much cpu, but it does get the job done. There is another issue now, the latest firmwares seem to have caused an issue with small buffer sizes being shared (think 10ms). There’s a lot of noise. Even at 250ms, I seem to get some crackles and even then is too much latency for a live non/delay effect.

1 Like

Is it possible that whenever people are sharing buffers that 99% of the time they are just doing it to get around routing limitations? :thinking:

If so, that would alter some priorities…

3 Likes

Not by default but i do use it this way also

Alter priorities to the Favour of routing possibilities… sounds good to me!

Honestly, the routing is the biggest thing that’s missing right now. (Beside log envelopes).

However, i find myself to use the 301 in ways of a hub in which the rest of my system ends up in. The recent shared 3 op synth uses an inspiring approach, i admit i haven’t really explored this way of thinking towards the module. I like the matrix approach, have to try that :slight_smile:

1 Like

The biggest use of shared buffers for me is process driven music… using a buffer like a spool of tape that goes through multiple machines.

Maybe this is a good thread topic?

4 Likes

Definitely not 99% of the time. A good amount of buffer sharing is being able to use something like the granular units for real time processing as opposed to processing a sample.

I’d almost say it’s even 50/50 split here. Sharing buffers for routing becomes essential when wanting to create a wet/dry control on an effect or something like that.

2 Likes

in my case this is 99% of the time - which I would say brings a performance hit too

I remember a thread way back where we talked extensively about send/receive, I thought it was one the “to-do” list ?

1 Like

this was the thread…

https://forum.orthogonaldevices.com/t/units-and-the-potential-for-additional-outputs/287/11

Actually I think the original thread was on the old forum - I can’t find it here, but it had a lot of good ideas.

@tom_hall I’m talking about prioritization not whether it is on the todo list or not :wink:

1 Like

I should have been clearer, I couldn’t see it anymore on the “to-do” list, hence the question :slight_smile:

glad to hear it’s still there