Page 1 of 1

Feature requests and ideas about their implementation

Posted: Sat Oct 06, 2018 6:17 pm
by kyouko
Hello NightRadio and everyone else,

as is the title of this thread, I have some feature requests and some ideas about their implementation.
I apologize if others have created similar features already, but reading through everything is quite the hassle, and I believe that my actual suggestions might have some worth too.
Anyway, to get to the point:

Note-level-ADSR:
From the looks of it, having ADSR for any signals volume, is impossible at a per note level.
All ADSR implementation I have seen, seem to be monophonic, and can only effect the volume parameter of the whole module.
So playing a note after a chord, makes the whole chord have full volume again. This kind of sucks.
Just adding an ADSR control to every instrument would be quickly done, but it possibly comes at the price of backwards compatability, and probably isn't the most modular solution.
One can individually set any notes volume in the tracker though. So it seems like volume is a property of the note, and can be used by any generator.
So adding a new module, maybe similar to the glide module, which handles per played note volume or possibly even other controls (vibrato etc.).
In it, one could have a place where one could draw the progression of volume at a tick-level, or just have normal ADSR controls.
This way, having things like stabby synths, or tracking leads, would become much simpler and more enjoyable, as one wouldn't have to manually set the volume for every note in the tracker.
famitracker has something like this if I remember correctly.
Also I am sure it would be really great for the modular nature of SunVox.

Upwards compression:
I wanted to try and reconstruct something like OTT for SunVox, but without a straightforward upwards compressor it just doesn't work nicely, or rather at all.
So, just adding one would be very nice.

More note logic:
Something I have wanted for example is a way to send every next note to the next receiver in succession.
This way a lot of nice synths could be build for sure. And I think one could even build synths that solve most of the Note-level-ADSR problems.
Still, I think note-level-ADSR is worth having, and less computationally intensive.

LFO frequency of completely 0, or just a constant signal module:
while trying to add some panning features to a synth I was building, I started wanting this.
I know the generator has this already (kind of), but it may be slightly better for the cpu if it was just constant. Also, the generator has to be triggered before it can work.
As for the LFO, compared to the generator method, te LFO works constantly and doesn't need to be triggered, so this might be a good way to go,
but changing the lowest frequency value to complete 0 might break backwards compatibility, so maybe a constant-module might be worth considering.

These are just some thoughts I had while using SunVox.
I believe the note-level-ADSR thing might be the most important one, and could greatly increase my and other peoples enjoyment of using SunVox.
I don't know how open you are to having someone help you program these features, but I would gladly help.
I have a lot of free time currently anyway. Also I don't care about credit or whatever, I just really want to have some of these features quickly, so that I can make music with them.

Anyway, thank you NightRadio for this amazing program.

Re: Feature requests and ideas about their implementation

Posted: Sun Oct 07, 2018 5:53 pm
by Logickin λ
For the "constant signal module",
Have you tried amplifier with 128 value of dc offset?

Otherwise, I agree with the Note-level-ADSR. What I am doing now is to create 8 set of identical synth to create 8 note polyphony, which may not be the most convenient solution, since it take 8x number of modules (hence lower the performance).
This will save a lot of time and effort for creating sound, but the biggest challenge should be how to backward compatible for older synth that only using Attack, Sustain, Release.

Re: Feature requests and ideas about their implementation

Posted: Sun Oct 07, 2018 7:39 pm
by kyouko
If a new module is created, which just changes affects the note information, then backwards compatibility will be no problem.
This is similar to the glide module right now I believe. It (probably) affects the note information, and not the audio signal.
By introducing an ADSR module (or 'note information envelope' module if it is supposed to be more general case) everything from past versions will still work without a problem.

Also thanks for the DC offset amp tip. It is a bit simpler than the other solutions.