Ramp osc never reach zero?

Hi!

I´ve set up a ramp osc to control a sine wave. Every time the ramp "wraps around", I want a value of one send to a counter. My first thought was to "listen" to the zero at the beginning of each ramp and have it trigger a constant of one. But the ramp osc doesn´t seem to ever reach zero! (and not 1 either. It comes really close, but does not touch the integer "one")

1. Is there anything I can do to provoke a zero at the beginning of each cycle?

2. If not, how can I make the counter raise it´s value by one, each time the ramp wraps around?

- T

 

I'd try listening for a value of something like 0.0001 instead of zero.

 

no that's not a solution because there will be some „ramp-drop outs” too (sometimes) or you get some events twice
On computers you will never test an exact value if you are using float numbers.
Normally you have a ramp oscillator running from -1 to +1. Mostly it will not reach -1 or +1 exactly, only sometimes for frequencies which are a factor of SR=44100.
The common trick is to count the zero-crossing (rising part).
If you want to get the change from top to bottom you can use the wrapping.
If you are using a core cell oscillator (4-Wave-Mst) you will find a part which recognizes the wrapping (mostly an -2 operator).

after the wrap output you have to analyze a (+/-) zero crossing. If you send a logic event you can separate the event.

You have to use core if you want flexible solutions.

ciao herw

 

Hmm, I should've been more clear. I assumed that the primary-level ramp oscillator is being used. If that's the case, and it's not reaching zero, then try testing for the value <= 0.0001 with a comparator. This will generate a tiny pulse at (or very near) the beginning of each ramp cycle.

 

Various ways to do this - ideally as a side effect of some other process.

Here is a simple stand alone approach using a core cell.


Col

 

ramp gets stuck

The amount of knowledge at this forum is overwhelming!
Thank you for your time and wisdom!

Before I wrote the initial forumpost I did as you suggested, Chet, and listened to a value very close to zero. This seemed to work, but as Herw pointed out, I got the events twice, especially at low speeds. I guess the comparator-trick would get mu out of it!
As I have no experience with Core, I tried a different approach which in many ways turned out quite nice:

Instead of the ramp OSC, I turned to the ramp ENV. It provides all the functionallity I need but one: I need to have two following breakpoints, say 2 and 3, at the same level (some kind of "hold" implementation) but then the env stops at this point. It won´t continue through the rest of the breakpoints.
I notice that I have to make the last of the two breakpoints in question significantly larger (3-4%) to make the env finish it´s movement.

This, I most say, puzzels me!

-T

 

If an envelope generator will almost do for you what a ramp oscillator will do, I guess I'm not sure I follow what you're aiming for.

 

Thanks for answering!
You're question is understandable, and it is perhaps likely that i hit this from a wrong angle. Even so, my goal is really simple: I am producing music from an old tape-music score.
To get it right, I have to control linear changes of frequency. At first, I thought of making a ramp osc to control the sinuswave. But, as the melodical phrases are no longer than five "turns" (breakpoints), the ramp env provides sufficiant control of both the linear changes of pitch and the time it should take to get from A to B.

Does this make any sense?

 

Yes, I think it does. Thanks for the explanation.