Cool... but can be done without code... not sure which will be faster.
Pilchard ·
oddson wrote: Cool... but can be done without code... not sure which will be faster.
Of course. I'm just assuming the code way is faster. Could be wrong though...
There's probably an even faster code way too!
infuzion ·
hmmm, does the Code's output get updated as each out is updated (eg OUTmixedL's Mono's stream is update, then OUTmixedR's)? In this Code, I'm shure it wouldn't matter, but perhaps in longer ones there could be L/R phasing introduced?
Pilchard ·
infuzion wrote: hmmm, does the Code's output get updated as each out is updated (eg OUTmixedL's Mono's stream is update, then OUTmixedR's)? In this Code, I'm shure it wouldn't matter, but perhaps in longer ones there could be L/R phasing introduced?
I see what you mean. I don't know how the code is processed over time. I would imagine it's only a neglegable amount and probably not noticable if used on a broad spectrum signal.
Splitting the left and right into seperate code modules would fix it if that were the case. I'm only 3 days in, so I wouldn't know if there was a better way to code it. If anyone does...... 🙂
oddson ·
I don't think coding like this introduces (additional) latency and hopefully not differential latency between output channels.
sambean ·
Think the code version is faster ATM as the calculation will use all the xmm registers, if you build the same code using modules, there will be intermediate values stored between each module.. small difference, but I believe Jorge said this would be an optimization added later..
infuzion ·
That sounds like a good explanation, cheers sambeam!
(kinda wish devs would get in converasations like this...)
Dave B ·
oddson wrote: I don't think coding like this introduces (additional) latency and hopefully not differential latency between output channels.
This processing should easily get done within a sample clock. I see no reason to believe it would introduce latency.
stefan ·
No latency is introduced. Not when using the code component, nor when using standard math components.
Pilchard ·
Good info guys!
Thanks!
infuzion ·
cheers stefan
BasherT ·
I am new to this synthmaker lark but am trying to make a dry/wet mixer without using code. I seem to have managed it but the volume reduces as the "wet" mix increases. Any ideas what I am doing wrong?
mixer.osm
Thanks in advance for any help that might be offered
oddson ·
I just did a quick check and it seems your module is doing what it should.
The likely cause of the appearance of reduced volume is that wet signals often sound less loud - especially reverb/delay effects.
There are some ineffieciencies in your module. You're doing the same 1-x math for both wet and dry and you're doing it at sample rate (44,100 times per second to get a near static value).
This is better:
oddson ·
A simple scale factor added to the wet side can give you a more even sounding mix.
Oh, and the other reason the volume may drop is if the wet signal is out of phase with the dry and is cancelling.
Pilchard ·
LOL. I forgot I made that...
I did that when I teseted the demo!
Might come in handy. 🙂
Wrote something here? To have a post removed or your name hidden, write to [email protected].