I’ll do several experiments asap, controlling a dc offset should be enough, but from the first tries it seems to be too slow.
I’ve got to use a +500BPM & +128LPB to make it work directly like an oscillator.
So for now, I keep on trying to control a ringmod frequency with the formula device, where specific math. functions, are modulated through incoming ABC params.
For example, the A = keytracker input, the B = signal follower, and the C=velocity tracker, things like that.
Not that easy, but usefull especially when you want to create odd sound fx.
Depend on what frequencies you want to get. As I said my example above generates audio at a simple 180BPM 4LPB.
Although sure you can get some far more interesting results with this method!
I’ve discovered that the “user” tab had a f(x) = inv (x) function !
that’s a very cool thing, especially when I want to perform some sidechainings… 
I assume you’ve clicked the question mark (?) and seen the list of operators and variables available to the Formula page?
Can’t remember off-hand what language the User page is programmed in but it has been mentioned on these forums somewhere (think C, maybe LUA…)
Yes, I’ve clicked on the “?” small button.
Very interesting.
Considering the list of musical variables, it looks also easy to create BEAT controlled fx.
I think that the language is LUA, as mentionned by kraken here.
This device could also behave like a “if - then - else” thing.
The problem is that I even never took time to check the LUA scripting language.
For now I make lots of tests, but I got only one week for the competition.
I think it will give me the opportunity to activate my few existing neurons and maybe code some nifty procedures/funcs.
Thanks for hunting down the response I was alluding to. LUA it is then 
Have thought about this but as of yet not made any tests…
Beat controlled? Well cyclic and timed to beats/line yeah but that’s just replacing the LFO really. Also can have it so it works more like a stepper, so rather than the smooth automation of the automation curves you get one change per line or similar.
Barely touched it myself as yet to be honest…
Well that was kinda the hope for this round
Still testing the formula thing.
There are some limitations of the LUA access in this user box.
For example, you can execute this line of code through the lua scripting terminal,
renoise.song().tracks[1].color = {0xff,0x00,0x00}
And it works, it changes the color.
BUT if you insert the same line inside a formula dsp user function, it simply returns a runtime error…
I suppose that the dev team has willfully limited the API access in this edit box.
Maybe a full featured formula box could make the GUI and the audio timeline slower…
Yeah, IIRC kraken/gore mentioned it is all running in the audio thread [which of course has top prio in an audio application], so you don’t want to do GUI stuff in there.
BTW, there’s (a) typo(s) in the “?” help text, e.g. a mod(x) doesn’t make sense, it has to be something like mod(x,y). Modulo needs two arguments, or it wouldn’t make any sense at all. Anyway, probably you would use the (binary) % operator rather than the mod function.
Anyway, I definitely like this hidden device, thanks kazakore for pointing it out. Probably I won’t have enough time to get an entry done, too busy with other things ATM, but experimenting with it is a lot of fun.
yeah the only way to perform a modulo is to use the % operator…
… BTW since we speak about problems,
- I can’t properly save a .xrnt with formula devices in it, when I save a chain, It store the default device and nothing else… so I’m obliged to store my chains in a .xrns…
- I can easily create renoise crash / fatal errors with this highly alpha device…
Crash:
- create a new song, only one track
- add a few formula devices in it, chain them in a track with other known devices (ringmod),
- save the whole thing in a .xrns file
- close renoise
- restart renoise
- load the .xrns track
- after a few seconds : a fatal error - termination process starts, & you need to restart the computer to flush the ram from something buggy that’s stuck in it
- if you don’t restart the computer, the .loaded xrns systematically makes renoise crash
That is Renoise API code, not LUA code! I understood is used LUA, not it uses the API and it’s Functions.
Strange. I can save and load both .xrnt DSP Chains and Presets containing/for the Formula Device no problems. Can you copy and paste between Renoise instances?
Can’t get it to crash at all following those steps or any other so far. Have you maybe added something strange to the User (or even Formula) sections?
What OS are you using? Seems OK here on WinXP SP3. Going to be annoying if people can’t compete due to instabilities on certain platforms! Hopefully it’s just something you entered though…
It crashes here aswell, i thought i lost all my work, but i was able to open the xrns with the formula device after a reboot. A very annoying bug though if that happens every time.
Been open and playing the xrns with the Formula Device in it here for over 9 hours in the background (no actual audio) and no crash or instability seen at all.
EDIT: Actually think I’ve managed to break it by using a fair few more Formula Devices in the chain. Took out the Audio Thread even thought there was no samples/instruments as well but I knew that chain would be suspect (having Formula Devices affect ones that are affecting it.)
Strange thing is I can save and load the same DSP Chain but if it’s the only thing in the song loading the song will crash Renoise.
I only used one formula device. The crash does not appear when the track is running or anything, it’s just every time i try to open up the xrns except the first time after a reboot.
Same thing here. The reboot is the only workaround I’ve found.
EDIT : now it’s worse, after a few reboots the workaround doesn’t work anymore, each reload of the .xrns file will crash renoise… even if the computer has been rebooted… I think I’ll have to restart to program my test chains from scratch…
Additionnal Note :
What’s strange with the user defined funcs, is that once they’re defined in the song and are working, I could use them in another formula device, located somewhere esle in the track… (?) until renoise is closed and the song is reloaded. Renoise seems to consider somehow that some “local” variables and functions, once correctly defined, are “global”.
I 'll try to see if different parameter names and different function names, could avoid some mismatch in the audio routine at runtime and make renoise more stable - … or not.
Has anybody found this stable enough to even try and get an entry done? Or should I go back to the winner of the last round for some rules next go? Have to revisit this when the new version of Renoise comes out as apparently this bug has been fixed 
even if no song comes out of the compo, at least the dev-team will have their ‘highly-alpha’-device tested pretty well.
Yep boys, after a few days of formula device crash / tests / explorations, I’ve started to track this afternoon, my own deadline is near … (heeeeeeee very near, 8mn left, I’ve got to hurry up…).
EDIT : okay it’s finished.
Concernng the *formula device, I didn’t want it to make renoise crash after loading the track so I tried to work with some willfull limitations in mind :
- not more than 1 *formula device per track
- no *formula devices chained to other *formula devices, directly or indirectly
- user function names and declared user function variables must have very different names
- renaming the *formula device names, its parameters names, and connected DSP device is not recommended
When I respect these kind of rules, Renoise works correctly without any crash.
After that, my song’s finally so basic… nothing revolutionnary, anyway I’m sending it to kazakore through the PM system.
In such a “race against crashes”, you are indeed all champions 