SynthMakermaestro ·
How I can reverse the phase of the wave with SM? (180º) Sure it's something simple but can not find the way
thanks to all cheers
(and as always sorry for the grammar, it is translated with google haha)
Reverse phase
From the original SynthMaker forum (2004–2014), with its members’ names and dates.
Sasu Honka ·
Multiply the poly audio with -1.
trogluddite ·
Though it does depend on what you mean...
Multiplying by -1 is a polarity inversion (turns the whole waveform upside down) - for a simple sine waveform the effect is the same as a 180deg change of phase. You use the word 'Reverse', so Sasu's answer is probably the correct solution to your question.
But, a phase shift (in degrees) is not always the same thing. I won't explain here - but here is a link to the Wikipedia definition (there should be a link to your language there - easier than trying to translate)
maestro ·
Well I mean the typical control to invert the phase which comes in many plug. inversion the polarity of electricity
The word is inversion, reverse no, sorry, put the word google is not and I did not realize. thanks
trogluddite ·
No worries 🙂 - it's the people who make mixers etc. who are to blame; they always seem to use the wrong name for it, even though they really should know better.
maestro ·
yes hahah, con el idioma y ademas los nombres tecnicos, estoy siempre confundido hahahha 🙂 edit: hahahah the end I spoke Spanish without realizing it hahah 😀
Tzarls ·
hombre, menudo lío! 😀
trogluddite ·
El idioma de los geeks se hace para confundir a la gente de todas las naciones! 😉
maestro ·
damn those who built the tower of babel hahhahaha did not make us a big favor. Back then, I'm a newbie with SM (as in the languages:)) as I can multiply the audio signal by -1? I have been looking in math operations but can not find how to do it (although that should be fundamental) right now I'm on the level of some modules combine with others, but still not doing many things. thanks again for your help mates cheers!!!!
oddson ·
The Stream Multiply primitive is what you're looking for. Once you hook it up to a poly (white) or mono (blue) or quad (blue with four-dot connector) it will take on that colour and function.
It's also what you use too emulate a VCA (voltage controlled amplifier) but in that case the second input comes from a control or modulator instead of a constant (as shown here).
trogluddite ·
In SM2, the maths modules for streams are in the DSP folder. It's still driving me insane the way they rearranged the folders for SM2!
maestro ·
ahhhh ok, knew how to multiply operation but not where to put the -1. Now I have very clear how it works. Trogluddite and OddsOn, thank you very much. 😀
Savior Calabro ·
What do you think? 🙂
trogluddite ·
Hi there Savior, welcome to the forum.
Good to see you making nice examples for your first post 🙂 I'm going to suggest a different method, and compare how they are better in different situations...
Compare these two different ways - surely the same?
The top one (yours) switches the audio signal itself - this has a very useful effect. When the output from the multiply is disconnected, it stops using CPU power. This works even for big modules - break the output connections, and less CPU s used. So what's the catch?...
When the switch changes, SM has to make changes to the way that the plugin program runs - and this can sometimes make modules n the schematic reset themselves, and notes playing on your synth might get switched off.
In the second version, only the 'green' control signal changes - so there is no saving of CPU (the multiply still has to work) - however, it can prevent the problem of notes getting cut off, because the route taken by the blue audio links never changes. It also has the advantage that you can use a 'de-zipper' after the selector to smooth the change from -1 to +1, which gets rid of 'clicks' when you move the switch.
Both are good in their own way - CPU vs. smoother switching, pick whichever suits you best!
infuzion ·
trogluddite wrote: In the second version, only the 'green' control signal changes - so there is no saving of CPU (the multiply still has to work) - however, it can prevent the problem of notes getting cut off, because the route taken by the blue audio links never changes. It also has the advantage that you can use a 'de-zipper' after the selector to smooth the change from -1 to +1, which gets rid of 'clicks' when you move the switch.
Both are good in their own way - CPU vs. smoother switching, pick whichever suits you best!
As always, test what is said here yourself:
Strangely, due to how newer CPUs report CPU usage, if you connect both the Selector & Multiply together, it reports only 3 cycles. I think it should be more like 4 or 5 due to how SM works... but you get the idea. Also, IIRC, Selectors in older CPUs like my Athlon64, the Selector took about 6 cycles, so using just the multiply is faster CPU.
But I can confirm everything else Troggie said is true. You have to decide according to your specifications what approach is needed.
trogluddite ·
Ah yes, thankyou for the correction.
In this particular case, infuzion is perfectly right - because the multiply is such a teeny weeny device, the CPU saving is cancelled out by the CPU needed for a selector that is carrying audio. And when switched on, you have the CPU of a multiply AND a stream selector. So actually, for this application, version 2 (switching the green) is always the better solution, because the switch never carries audio.
As he says, the general principle is right - when switching a larger chunk of 'effect', the "turned off" CPU saving would be bigger, so using the stream selector would then be economical.
PS) It may not be just a matter of how newer CPU's report clock cycles. With newer chips it becomes almost impossible to work out how many operations are able to be run 'out-of-order' (or how many variable values will be subject to a cache miss) - so adding together the cycles of individual primitives is unlikely to ever be a reliable guide to the CPU usage of a complete chain. Choosing primitives with the lowest CPU hit will still give you the best probablity of a mean, lean schematic, but only real-world testing will really tell you just how efficient your design really is.
infuzion ·
trogluddite wrote: PS) It may not be just a matter of how newer CPU's report clock cycles. With newer chips it becomes almost impossible to work out how many operations are able to be run 'out-of-order' (or how many variable values will be subject to a cache miss) - so adding together the cycles of individual primitives is unlikely to ever be a reliable guide to the CPU usage of a complete chain.
Atom CPUs run in order IIRC, aside from simultaneous operations that happen to be next to each other.
MegaHurtz ·
Altho there would not be a better way of estimating cpu usage, its simply the loss thats made by decimating the units to fit a 1/100th scale. so its actually the user who is not equipped to estimate the numbers with enough resolution.
Given a good digital signal processor wont miss at all. And its mostly ram that would slow a cpu down. There would also be arguments not to include windows into the chain, (or very little) for better overall performance, given the nature of Synthmaker the loss of letting strings in and out of windows will be tactile. Wich i personally reckon to be a good thing for music. For example a coded version of a midi in transform will yust be feeling faster hands down.
oddson ·
I'm confused... 😕
infuzion wrote: Strangely, due to how newer CPUs report CPU usage, if you connect both the Selector & Multiply together, it reports only 3 cycles. I think it should be more like 4 or 5 due to how SM works... but you get the idea. Also, IIRC, Selectors in older CPUs like my Athlon64, the Selector took about 6 cycles, so using just the multiply is faster CPU.
Does a selector running audio through it really add to CPU usage on an ongoing basis if there are no green triggers coming into it?
trogluddite wrote: When the switch [feeding the selector passing audio] changes , SM has to make changes to the way that the plugin program runs - and this can sometimes make modules in the schematic reset themselves, and notes playing on your synth might get switched off.
Does a selector running audio through it really cause the audio process to reset?
infuzion ·
oddson wrote: I'm confused... 😕
infuzion wrote: Strangely, due to how newer CPUs report CPU usage, if you connect both the Selector & Multiply together, it reports only 3 cycles. I think it should be more like 4 or 5 due to how SM works... but you get the idea. Also, IIRC, Selectors in older CPUs like my Athlon64, the Selector took about 6 cycles, so using just the multiply is faster CPU.
Does a selector running audio through it really add to CPU usage on an ongoing basis if there are no green triggers coming into it?
No, Selector/Multiplexor use CPU when they are in stream mode. 🙂
oddson wrote: trogluddite wrote: When the switch [feeding the selector passing audio] changes , SM has to make changes to the way that the plugin program runs - and this can sometimes make modules in the schematic reset themselves, and notes playing on your synth might get switched off.
Does a selector running audio through it really cause the audio process to reset?
When the Selector/Multiplexor changes/is switched, it forces an ASM recompile of all the audio code. This in turn causes the audio process to reset. I should test if the same Int value is sent, if that causes a recompile also...
oddson ·
infuzion wrote: Selector/Multiplexor use CPU when they are in stream mode.
Right... I guess it has too. Never thought it through before.
infuzion wrote: When the Selector/Multiplexor changes/is switched, it forces an ASM recompile of all the audio code. This in turn causes the audio process to reset...
First part makes sense to me... but I'm not sure exactly what "This in turn causes the audio process to reset" means in practice.
It once meant that all audio buffers were interrupted as everything reset... but that was fixed years ago.
trogluddite wrote: ...this can sometimes make modules n the schematic reset themselves, and notes playing on your synth might get switched off.
I guess this is the part I'm puzzled by. Does this happen... shouldn't it happen consistently and not 'might' and 'sometimes'? 😕
trogluddite ·
oddson wrote: 'might' and 'sometimes'?
Sorry - Partly deliberate vagueness because I have so little experience of using poly, as I have never been a synth builder - and partly me being a little haphazard in my choice of words! For mono/mono4, have found that the effect depends on whether there are stage(0) sections anywhere. If there are not, then following the change, all variables keep their former values. If there are stage(0) parts, then they are the first thing to run following the change, with whatever consequences are programmed in that part of the code. I have not tested this exhaustively with primitives - by the time I was aware of the "problem", I was already in the habit of using code/assembly for pretty much all of my stream processing. I would imagine that the only primitives likely to have stage(0) behaviour would be those that reserve memory for buffers (e.g. mem's). I guess I should have phrased t more like... "If you find you get a audio glitches when switching selectors, then here is one likely cause..." - I didn't really mean to give the impression that stream selectors should always be avoided.
oddson ·
Got it.... stage(0) executes with stream type data.
FYI - I tested with poly... stage zero does not execute when the selector changes.
Thanks guys. 🙂
Wrote something here? To have a post removed or your name hidden, write to [email protected].