Feature requests for 1.9.4

Koekepan
Posts: 263
Joined: Thu Dec 05, 2013 4:56 am

Feature requests for 1.9.4

Post by Koekepan »

I have a couple of requests.

Synthesis:

I would like a dedicated Karplus-Strong module.

Filter:

Any chance of a drive function on a filter, or alternatively a parameterised distortion module? Alternatively, an EQ module with more bands so that arranging parameterisation of functions can be done with more precision?
Comb filter

Effects:

Granular delay
Reverse delay

Utilities:

I'm still holding out hope for the possibility of a round-robin multisynth, to take full advantage of the huge sonic flexibility of sunvox.
TheMonopluralist
Posts: 52
Joined: Tue Jul 04, 2017 12:40 am

Re: Feature requests for 1.9.4

Post by TheMonopluralist »

Well if we are submitting requests for the next one already:

Midi clock sync!
Ideally in and out, but even just one-way would really help. I'm sure this is already on the to-do list but I thought it's worth highlighting just how useful it would be.

On the subject of multi-synth - a slider to select a single output connection at a time would be good for me.
Koekepan
Posts: 263
Joined: Thu Dec 05, 2013 4:56 am

Re: Feature requests for 1.9.4

Post by Koekepan »

A single slider doesn't buy you anything that you couldn't do by just directly triggering the target in your pattern.

Automated round-robin saves a lot of time when you have a monophonic patch and you want to use six copies of it, one at a time like a six voiced synth.

A 10-band Graphic EQ module (One band for each audible octave, more or less) would be great for working into compression or drive chains.

Karplus-Strong synthesis is possible in sunvox already, but it's a bit of a pain and takes a lot of modules, so making a fresh synth module for it would make a lot of sense.

Comb filter, granular delay and reverse delay are sufficiently their own animals that they, too, merit their own modules.
TheMonopluralist
Posts: 52
Joined: Tue Jul 04, 2017 12:40 am

Re: Feature requests for 1.9.4

Post by TheMonopluralist »

Actually, a single slider DOES buy me options when live-triggering, rather than playing preconstructed patterns, unless I have missed something fairly obvious. I didn't intend to suggest anything negative about your suggestions.

Edit: what about a "routing" module, that could allow re-routing of signals. It could be designed to allow both round-robin AND specific output according to parameter settings?
Koekepan
Posts: 263
Joined: Thu Dec 05, 2013 4:56 am

Re: Feature requests for 1.9.4

Post by Koekepan »

That's pretty easy to do already.

Put an amplifier module in front of each target of your multisynth. Then add suitable control modules in the chain, detecting (volume/note/whatever) to turn the amps up or down.

You don't even need a slider at that point; it's fully automated. Or you could directly link the amps to an additional MIDI controller such as a nanoKontrol or a BCR2000.

Problem solved.

That original case that I was talking about isn't really soluble that way, which is why automated round-robin is an open request.
TheMonopluralist
Posts: 52
Joined: Tue Jul 04, 2017 12:40 am

Re: Feature requests for 1.9.4

Post by TheMonopluralist »

Thanks for the suggestion. I'll try that over the weekend. Are you talking about placing the amplifier modules between the synth modules and the output, or do the amplifier modules unexpectedly also work on the control signals (that is, if they were between the multi-synth and its targets - which is how I would normally interpret "in front of")? The reason I am asking is because my personal use case requires limiting the amount of work the cpu has to do, and I feel that triggering a load of synth modules for no reason and then running them into null amps is probably going to add to this. I really do feel that routeability of note and control messages, at least from a multi-synth, would be helpful, particularly if it offered round-robin plus additional options.

Also, thinking aloud, if this is easy enough to do in the way you suggest, would it be possible with some tweaks to achieve your round-robin this way? Or just trigger the different targets in your pattern, if you aren't playing live?
Koekepan
Posts: 263
Joined: Thu Dec 05, 2013 4:56 am

Re: Feature requests for 1.9.4

Post by Koekepan »

Are you talking about placing the amplifier modules between the synth modules and the output, or do the amplifier modules unexpectedly also work on the control signals (that is, if they were between the multi-synth and its targets - which is how I would normally interpret "in front of")? The reason I am asking is because my personal use case requires limiting the amount of work the cpu has to do, and I feel that triggering a load of synth modules for no reason and then running them into null amps is probably going to add to this.
There are a couple of cases here.

The first is where you have multiple synths that you want to have playing under various conditions, but where you cannot guarantee ahead of time which will play how loudly into their respective signal chains. Here, the amps are the correct response because they can be modulated to control relative levels.

The other case is where you really want only one to signal at a time, as per a velocity determination. This is easy to do, but in the other way around: use nested multisynths, with the secondary multisynths using velocity curves that are 0 output, except where you need them to sound.

Either way, you need nothing new, the current module types will do exactly what you require, and you won't have to trigger a single module's sounds any more than required for your output.
I really do feel that routeability of note and control messages, at least from a multi-synth, would be helpful, particularly if it offered round-robin plus additional options.
It's already routable. It's routable by signal, or capable of triggering down-chain results in a vast array of different ways.
Also, thinking aloud, if this is easy enough to do in the way you suggest, would it be possible with some tweaks to achieve your round-robin this way? Or just trigger the different targets in your pattern, if you aren't playing live?
No, and here's the difference: the previously mentioned methods are effectively stateless. They operate correctly regardless of the previous condition of the multisynth(s) and the signal(s) travelling down the signal chain.

Round-robin requires at least a record of which output was the last to get a signal, so that the next one can be selected. This does not currently sit in a multisynth, and while it may just be possible to figure out a way of retaining enough state across a series of modules to hack this together, it's way beyond (in control complexity as well as overhead per function) a couple of extra amplifiers or multisynths for a mutable patch.

If not playing live, as I pointed out above and elsewhere, yes, I could manually toggle every individual one on a different synth time after time, but that's a lot of additional work that would be totally unnecessary if we could just do a round-robin option - and it would be completely impractical in live situations.

TL;DR: what you described is conveniently possible in a couple of ways, depending on details, today (and has been since at least 1.9.2) while what I described is maybe possible - but if so is very difficult, and bears a lot of overhead, because you have no easy way of building a high-speed accurate event counter and using it to toggle mute states.

Edited to add: Smart round-robin that goes for unused targets first, and then oldest sounding (so as to minimise note-stealing) next would be a great option to have, but even basic round-robin would be an advance on the current situation.
TheMonopluralist
Posts: 52
Joined: Tue Jul 04, 2017 12:40 am

Re: Feature requests for 1.9.4

Post by TheMonopluralist »

Thanks for the full in-depth on this. Of course having written the out-loud thought I realised that the current-state (and therefore round-robin ticking) problem was the most obvious difficult bit for your intended use cases, just wondered if there might be a clever patterns within patterns module way of doing this. Looking at some of your posts on here clearly you have been thinking about this for a while.

As for my personal use case, I'm sure the nested multi-synth module option could be of some use. I have played with velocity splits before. In fact for my case a velocity curve is not the answer, as I literally want to queue up a whole series of different synth/sampler modules, with the ability to select the routing to one at a time (via a midi cc dial), while maintaining the ability to highlight a given module to expose the parameters. I'm guessing that using a nested multi-synth system would require resaving all my modules in a nested form if I wanted to be able to see the parameters when the top-layer module was selected (observation, not complaint). I am sure there probably is some kind of creative way of solving my exact problem. I don't expect you to do it here for me.

N.B. I have tried not to criticise your request, I see no problem with it. I don't want any of my posts here to be seen as dismissive of it. I have suggested slight additional features (if automated round-robin is doable, the related feature of selectable destinations does not seem unreasonable to me). I'm not sure you are acknowledging that even a simple workflow improvement is a valid feature request, although I do understand that your request for an as-yet unsupported feature would be worth giving priority (if they weren't so interlinked/related as to make it worthy of consideration as a two-part tweak). I don't necessarily think framing it as "your feature request... while my feature request..." was intended to set it up as a "A or B" dichotomy, but could be read that way.

N.N.B. I am also aware that unless and until anyone else steps in, my specific idiosyncrasies related to my intended use may be entirely unique.
Koekepan
Posts: 263
Joined: Thu Dec 05, 2013 4:56 am

Re: Feature requests for 1.9.4

Post by Koekepan »

My problem with evaluating your situation is mostly that you haven't gone into a lot of depth on precisely what you're trying to achieve. As far as I can tell so far, you want to select which module to trigger on the fly. Depending on your controller, you can do that directly in 1.9.3 by just preparing MIDI channel settings on the modules, then changing channels. You say that you aren't after velocity switching, but you don't really say what kind of switching you're hoping to achieve.

Based on what you're describing, the more elegant approach may be to have MIDI CC signals set to toggle module mutes - which is something that I believe other people have already requested in the past. I don't think it's available (yet).

You're right that a manually selectable routing option could work, but then what if you want to send a signal to two out of five? That is why I think that a slider, as you propose, is the less general solution. Toggles have a lot wider application.

It might make sense for NightRadio to consider a non-multisynth signal router module, that has a couple of modes: strict round-robin, smart round-robin (that minimises note-stealing), and manual toggles.

Would that work for your use case?
TheMonopluralist
Posts: 52
Joined: Tue Jul 04, 2017 12:40 am

Re: Feature requests for 1.9.4

Post by TheMonopluralist »

You are right, I hadn't given enough information for you to evaluate my use case specifically. To be fair, at the outset I hadn't expected evaluation of my uses, it was just a feature request until we got more into it. I figured that the feature request would be enough (hopefully) for others to see that it might also benefit their uses. Yes, midi channels is an option I considered, although this limits the number of modules. I had hoped I was clear enough finally on the basic switching I would appreciate (selectability of a number of modules by midi cc dial - that is, the ability to scroll through the relevant modules), and I only now appreciate your point about a slider not being the best option for some uses, in that it limits you to a single destinantion, and the toggles would allow different combinations, although it would make the scroll-dial selection more difficult.

If your last suggestion could also have options like: "single/multi" and "destination if single/primary destination if multi or round-robin" - I know it becomes slightly more convoluted, but might accommodate both requests. That convolution is the trade-off, of course!
Koekepan
Posts: 263
Joined: Thu Dec 05, 2013 4:56 am

Re: Feature requests for 1.9.4

Post by Koekepan »

After some thought, I don't think that your proposal is invalid, but it is not the most elegant way of approaching the problem.

Consider the following proposal:

A routing module that has a few modes.

The first mode is strict round-robin.

The second mode is smart round-robin with oldest note priority, where unused channels are preferred, and when those are exhausted the most recently started notes are stolen.

The third mode is smart round-robin with newest note priority, where unused channels are preferred, and when those are exhausted the oldest running notes are stolen.

These three modes are monophonic per output.

The fourth mode is multitimbral manual output toggling, where any subset of available outputs can be toggled on.

The fifth mode is monotimbral output toggling, where toggling any one output on automatically toggles the other outputs off.

These two modes are polyphonic per output.

The round-robin modes could also support a monotimbral option, where a new note ends old notes. This would have a variety of uses, for example where you have subtly different output channels to add more life to a given patch, rather like an old polysynth with subtly different oscillators.

I understand that you'd like to scroll a wheel to run through available outputs, and I suppose that would be feasible. If you insist on having a slider that you can scroll, then that slider would be meaningfully active only in some of the monotimbral modes, but it's not elegant to have interface elements that sometimes do something, and other times not.

I have more or less the same gripe about the duty cycle slider in the generators. I'd ideally like to see duty cycle applicable to all shapes.
TheMonopluralist
Posts: 52
Joined: Tue Jul 04, 2017 12:40 am

Re: Feature requests for 1.9.4

Post by TheMonopluralist »

Indeed.

I insist on nothing, of course, but would be happy to see a slider. I do like your idea for the inclusion of round-robin modes.

I was concerned specifically about the inelegance of options that only "sometimes do something", but couldn't easily think of a more elegant way. I also noted there are examples of this already, such as "filter envelope on/off" toggle enabling other parameters, for example.

Anyway, a good discussion of some of the relevant issues! I know it's up to NightRadio ultimately how and what he implements in terms of future development, but it's good to thrash out these ideas on here where there's room for debate, and it helps expose where issues really exist (or don't).

I would probably use at least one of the round-robin modes you suggest, and a routing module of some sort might provide a relatively open set of utilities/functions.

Edit: as for an unused physical slider as an interface element being less than elegant... fortunately I have a controller with recallable programs (midi channel and number assignments) and I set these up to be used in different modes, to which I would probably add one to use with round-robin synth patches. This, I concede, is specific to my case and is not the case for all users.
End edit.

P.S. This thread became so much about one feature request area, have you considered deleting most of the opening post, re-titling the thread to reflect this and re-posting the original post in a new thread?! I'm just worried we might have scared off some other potential suggestions and denied the thread the opportunity to retain your original intention!
Last edited by TheMonopluralist on Sun Nov 26, 2017 2:04 am, edited 1 time in total.
TheMonopluralist
Posts: 52
Joined: Tue Jul 04, 2017 12:40 am

Re: Feature requests for 1.9.4

Post by TheMonopluralist »

Is the issue with the duty cycle at a deeper level? I mean that I would guess (because I don't really know) the synthesis of duty-cycle in non square waves is a whole kettle of fish in itself, great tho it could be.
Koekepan
Posts: 263
Joined: Thu Dec 05, 2013 4:56 am

Re: Feature requests for 1.9.4

Post by Koekepan »

No, I just like duty cycles as an additional way of sound shaping.

Well, that and having a control that does nothing because I set the curve to sine.

As for another thread? Enh, I assume NightRadio has a list in a spreadsheet somewhere. I trust him!
zeffii
Posts: 32
Joined: Sun Apr 05, 2015 2:05 pm

Re: Feature requests for 1.9.4

Post by zeffii »

here's the list of things that I think could make a big impact on how fast I track.

a few usability features. I mention these because after a few hundred hours of Sunvoxxing (which i really enjow btw) i find myself doing a lot of repetition.

- highlight the patterns that have control of a specified/selected module.
- right now we can highlight a module number in the pattern, is there a way to make that the active module too?
- the remap feature detects the most prevalent "from" value, but could also suggest the "to" value if there's a module active (this active module is usually the one you want to remap values into)
- a keyboard shortcut to rescale the current selection's Volume parameters. (like impulse tracker has.. this is great for fast manual explicit fade-outs)
- make cloned pattern unique.
- set a default pattern track count. i like 7 or so.
- highlight cloned patterns of a selected pattern (right now you only see if a pattern is cloned, not if a pattern has clones : I realize colouring patterns is a good cheap alternative)
- automatic colour randomization for new patterns, or Hue modifications if a pattern is being duplicated.
- modules to store/restore their current settings from a pattern command, much like setting program/bank in a vst tracker. or like buzz's "peer state". settings including extended properties that can't be modified from the pattern.
Post Reply