It is impossible to shift an audio waveform 90 degrees so that it retains the same shape.

if you want to delay something, pick a delay?
and just delay it?
that timer you are looking for is built into a delay?

if you want to let act that delay only on the positive or negative part of the waveform, split it by a separator and recombine it afterwards by just adding them.

it would be really helpful (for us and you) if you answer the question if you want to build a fx (waveshaper) or more a oscillator.

 

some more bits.
all waveforms are usually generated by a ramp. which is a simple saw osc without AA.
now one let run these ramp into formulas.
in case of a pulse it is simple. just use a separator. the output will be a pulse 50/50.
that outcoming zeros needs just to latch a -1 to get it bipolar.

creating a sine is running a ramp into a sine function.

the ramp is always the base just like your excel plotter needs to generate its graphs. it just happens hidden. you need to replicate that hidden ramp.

 

The Hilbert macro I posted does exactly this by implementing an array of 1-pole all pass filters. There is no secret here - the idea has been widely known for a long time.
The Hilbert transform was discovered/invented over 100 years ago. There has been a lot of research in this area since then. You will find papers explaining the details way better than I can, and others describing much better approaches and implementations than the simplistic version I posted...

Not sure what your ultimate aim is (it seems it's not what you were describing in your first post) but anyway...

The problem here is not the timer's lack of audio input - it's trivial to build an audio rate timer in core. The problem is that if you convert the sine to a pulse in the way you are suggesting, you lose timing precision.

Audio runs at some constant rate - 44.1Khz or 96Khz whatever. Using the approach you describe means that unless the wave you are processing is at a frequency that is an exact divisor of the sample rate you are using your result will be inaccurate by up to (just under) a sample tick. That doesn't sound like much, but as the frequency of the input rises, it becomes more and more significant, and will definitely be audible.

There is not an 'easy' solution.
One possibility would be to look for positive zero crossings in the input waveform, use interpolation to calculate the sub-sample position of the crossing, and put a timer on that. Even with linear interpolation, this will be much better, but it will only work with simple inputs. As soon as you have an input with more than one positive zero crossing per wave cycle... or polyphony... then it will fail.
A more advanced approach would be to use auto correlation to find the base frequency, this will handle multiple zero crossings, but will still struggle with polyphony.
So if that's still not good enough, then you are into the realms of frequency domain processing using maybe some sort of advanced wavelet or Fourier analysis to calculate the base frequency (or frequencies in the case of a polyphonic signal).

Even if you do get these working, you will have to contend with the fact that there is inherent latency - you always need to wait for at least one complete wave cycle before you can calculate the frequency, and this can take up to nearly two wave cycles (one incomplete cycle + one complete cycle), so e,g, at say 80 Hz, the detection latency for the 'simple' approach could be as much as 25ms (but it will be variable). For the Frequency domain approaches, it could be more than that depending on the implementation.

So as you can see, however beguiling this 'simple' and 'clever' idea is, there is almost always a better way. If you want to have lots of fancy waveforms, then it's better and easier to generate them from scratch - and there is a lot of information on the web about how to do it!

 

i highly recommend to have a look into the library HQ osc. there all our posts comes together and start to make sense in combination.
there is not really a difference in plotting a wave on screen or "plotting" it into an audiostream.



sorry, free cheap video recorder. part2:

 

So I managed to shift the waveform. Using timers. The problem now is that the sine and the square wave are shifted 90 degrees however when my synth plays a sawtooth, the sawtooth is only shifted 45 degrees. I'm close but no cigar. Hopefully someone can drop some knowledge as to why this is.

/why is this happening when I use the timer? Does it have something to do with cycles. I'm lost again.

 

i don't mean to be rude, but i gotta say, i get the impression that you aren't taking the time to read and understand responses that people are giving you here. which makes me wonder why i should invest time in answering your questions.

 

thanks for this words. my typical poor german translation would have sound way more harsh.

anyway.
it looks like bitwig 3 beta will start today, just like a new path of exile league. if i am done with that the gardenwork will eat up the summer as always.
i wanna give you active and helpful guys a big big thank you!
it feels like i have done huge steps in reaktor this winter season.
this wouldnt have been possible without your shared knowledge.
special thanks to colin, herw, mark and you.
i'll be back. but dunno when.
hope to see everybody in a good and healthy condition then!
all the best!

 

I DID IT! A perfect 90 degree phase shift for all waveshapes across all frequencies that doesn't change the shape of the signal. It's a bit primitive for now but it works. IT works. Thanks to all who contributed. I'll be honest it introduces a bit of jitter to the signal but its a clever little ensemble.

 

Perfect across all frequencies, and yet still primitive. It must be very clever indeed. I'm surprised you didn't post it!

 

Looks like a Kontakt script, so wrong forum here. Better chance to have a valuable answer in Kontakt forum.

 

"Audio runs at some constant rate - 44.1Khz or 96Khz whatever. Using the approach you describe means that unless the wave you are processing is at a frequency that is an exact divisor of the sample rate you are using your result will be inaccurate by up to (just under) a sample tick. That doesn't sound like much, but as the frequency of the input rises, it becomes more and more significant, and will definitely be audible."

Sorry I don't know how to properly quote, but I encountered this problem as audible crackling. I fixed it using an event smoother.

 

Still in wrong forum. Better post here : https://www.native-instruments.com/forum/forums/scripting-workshop.205/

 

I don't think the problem I was describing would cause crackling - and if it did, a smoother would not help at all, so that must have been a different issue.