Nice one! Thought you meant the Renoise status bar in the bottom left of the screen, this is better 
feature request:
randomize button
(maybe have every new instance of Resynth startup with random settings?)
Undo is still broken…
Originally I planned wavemod to do ‘something’ for sawtooth, but I couldn’t really find a function that made sense. It usually ended up looking like one of the other waveforms. Sawtooth modulation doesn’t appear to be common anyway, so I left it out.
As in reset all controls and parameters to as they are on startup? Would a button on the GUI or a menu item (‘Reset current instrument to ReSynth defaults’) be preferred?
Unfortunately, this is just a side-effect of the transferring of the samples when they get longer. Not much I can do about this really, it’s optimised as much as possible already. Sorry.
Yup, pitch, filter, panning, volume envelopes allow you to create some great sounds. Don’t forget the LFOs and velocity tracking too. You can make some nice ‘dubstep style’ basses with those.
I did originally, but then it looked wierd. This method seems more consistant, as other tools and actions may appear in the main Renoise status bar.
I’ll need to think about this. If we randomise all parameters we risk clipping. Also, do we randomise only ‘analog’ parameters and ignore wavetables? What if the user doesn’t have any waves installed? Overall I think a randomise function would affect only a handful of controls.
But it is consistent! 
I can hook some to some parameters (volume, panning etc.) to identify when they change outside the ReSynth GUI (e.g. on undo), however, I don’t think I can do this for the ‘internal’ parameters which comprise most of the settings.
A half-working solution is worse than a blanket statement that ‘undo may cause the GUI to become out of sync’. If you undo, close the GUI window and re-open, does that pick up the change?
A button on the GUI will be fine.
Maybe to celebrate the release we can have a comp featuring this along with native dsps. Perhaps the winner can either guest-host a special Remixta episode or visit local school and give positive message to kids to stay away from drugs and have safe hobbies like renoise and geocaching.
Nice idea. Looking forward to see some xrni’s made with Resynth2.
Wow, that is some serious hacking there. I like the way you store the parameters inside sample names. Tricky stuff. 
Yes, it makes sense to take into account the most musical controls, whatever that subjectively might be 
.
Maybe if no wavetables are present, only randomize the ‘analogue’ parameters (oscillator type, calm/harsh, mod/lfo/rate, trans, fine & pan)?
That seems to work; it’s not really a major problem once you’re prepared for it, but it threw me for a while initially…
Okay. Added to the right side of the ‘status bar’.
I could set easily all oscillators to analog and each analog could have random:
- calm / harsh setting
- waveform
- wavemod
- wavemod LFO
- transpose
- fine tune
- volume
- panning
but there would be a greater chance of an LFO with those simple settings, and with random tunings, volume and panning the result could be very harsh on the ears. Is this what people want? Discussions please before I implement it.
Ok. Good that it works. I’ll add something into the release notes to inform users.
Thanks everyone for the feedback so far.
I wouldn’t mind a randomization that incorporates tuning in the mix, harsh sounds could be useful creating synthetic drums or detuned weirdness for experimentation,…
…maybe you can have a default random button that doesn’t change the tuning and/or other dramatic settings, but right mouse clicking the button (or using some other modifier key) does randomize all parameters. Best of both worlds 
The following features have been added:
- Randomize oscillators
- Randomize tuning/mixer
- Reset to defaults
Has there been any issues with stability or any bugs found? If not I’ll push the final version to the tools page at the weekend.
RC1:
Wanted to open the GUI by the context menu in the instrument box:
std::logic_error: ‘ViewBuilder: invalid value for rotary encoder: ‘3’. value must be [-38 - 3].’
stack traceback:
[C]: in function ‘rotary’
.\gui.lua:321: in function ‘create_controls’
.\gui.lua:854: in function ‘display’
main.lua:166: in function ‘open_resynth_instrument’
main.lua:175: in function main.lua:175
Interesting error.
Do you have still have the XRNI? Would it be possible to send it to me?
Thanks
I thought you would asked me for this. But I’m sorry, I didn’t save the xrni 
Nevermind, I’ve identified the bug and can reproduce it here (set a volume of an oscillator to +3dB close ReSynth window and try to reopen it again for that instrument).
Renoise developers: I think this may be a bug in Renoise?
In rc1 open the file baseosc.lua and like 133 will be:
assert(dB <= 12)
This should read as…
assert(dB <= 3)
Which I overlooked when the reducing the maximum volume throughout the code. The bug then triggers this assert as 3 is greater than 3?
Why would an assert be firing on the test when 3 <= 3 return true?
The call is getting the parameter of 3 from get_volume which uses math.lin2db. Could this be the cause?
print(dB) in the function just prints a value of 3, no decimals.
I’ve worked around it for now by clamping the maximum volume returned by get_volume to math.min(math.lin2db(val), 3).
Thanks
Handy ReSynth tip #1!
Played notes will continue while changing settings (i.e. realtime auditioning and modulation 
) except if you select the noise waveform or change the LFO rate. (Release candidate 1)
Try it!
Development version already has all analog oscillator, tuning and mixer parameters available to modify in real-time.
Excellent for playing live with a midi controller (hint!)