lfo/square is limited to a maximum frequency of 207.7 Hz, right?
What if I want a higher frequency lfo, say 400 Hz?
Any way to achieve such a thing, e.g. the opposite of conv/nointerp?
thanks
Higher LFO rate?
Above 200Hz I would not really call it an LFO anymore.
But as a workaround, you can use the pitch inlet to transpose the LFO pitch outside its parameter range.
So tuned to 200Hz, and feeding it +12 (from a ctrl/dial for example) on the pitch inlet, and the resulting frequency will be 400Hz (12 semitones higher).
Another solution is downsampling the output of an audio rate oscillator is possible too. Just connect an audio outlet to a control rate inlet. Some objects will adapt their type to audio rate, if you need to prevent this, use the "conv/to f" object in between. When a red wire goes into a blue inlet, downsampling is implied.
ok, thanks!
I might be on the wrong trail here altogether though.
What I'm trying to achieve is to send X/Y/Z accelerometer data as 3 pitch-bends over (din-)MIDI,
and I find 200Hz a bit slow for my application. I would like higher time-resolution.
When I raise the lfo's rate the way you mention, midi/out/bend stops sending anything at all.
Is that a limitation of midi/out/bend, or a limitation of midi in general, or...?
DIN Midi can transport roughly 1000 messages per second, so with three pitchbends the practical upper limit is 330Hz.
MIDI USB Device to PC is not working properly yet, but would be a more practical solution to get sensor data into Pd or Max.
seems like another reason for us to also have multi range dials (L/M/H) in the future, I assume theoretically we can allow LFOs to go to 3kHZ (k-rate).
( I wonder, perhaps we could also allow the user to control k-rate... new object perhaps, so users can trade higher rate k-rates for less functionality in patch, always a compromise for cpu ... Reaktor allows this)
Selectable parameter mappings look attractive to me. In addition to envelope attack/decay/release rate ranges and lfo speed ranges, for instance a mix object could have different channel gain parameters set to linear unipolar, linear bipolar, or (semi)exponential scaling.
A parameter could declare a set of useful parameter mappings, rather than just one. But it is important to make the parameter map also visible in the patch. In my view, ideally a patch can be fully recreated from a screenshot. That means no object property/inspectors panel, unless the presence of such a hidden properties is unavoidable and obvious, like a script or subpatch.
Selectable k-rate would be interesting too.