Straightliner Update?

[rumba_codex]

Anytime soon?

Wasn't there a plan to the compile the OSC, Env & Filter presets (instead of trawling through the folders and folders of xml files)?

PS: Continue loving this synth. It doesn't do anything overly fancy but it somehow just fits into the mix so well.

[Music Engineer]

hi andrew,

mmhh...compiling osc, env and filter presets? i don't really get that. do you mean a reorganization of the folder structure? but i agree that there's some potential in these sub-presets that is kind of underexploited in the current release archive. i really should add more of such sub-presets. actually, i could easily obtain a whole lot of them by just saving sub-presets from the existing complete-synth presets. but it will be a nightmare to spot and avoid redundancies. some presets use the same or very nearly the same sub-settings - as a natural consequence of tweaking one sound into another. mmm...we'll see.

as for an update of the synth itself - i can't give a timeframe for that that because i'm currently considering to move away from my current GUI framework and roll my own instead. this will be a lot of work, but i expect a couple of advantages - most notably, less bloated file sizes. this will take some time. but maybe there will be an update before this is all done. however, maybe you should check back the latest download nonetheless because i have semi-recently overhauled the preset library (added a bunch and refined a few)

[rumba_codex]

Hi Robin,

OK, in the current design SL reads OSC, Env and Filter parameters from 100s of individual xml files. That's unusual in itself since most devs will cook up a number modules which are embedded in the GUI - all parameters included, as dynamic instruction sets.

If I've got this right (and I have no synth design experience to speak of here) you chose this xml based system since it seemed more efficient.

If you remember, we were talking about this last year. You were thinking that you could compile sets of OSC waveform values (for example) into a much small number of xml files.

Basically, I'm saying LESS not more files and folders or sub folders!

PS: Translation: if you're planning to roll your own GUI framework that would mean a move away from JUCE?

[Music Engineer]

Hi Robin,

OK, in the current design SL reads OSC, Env and Filter parameters from 100s of individual xml files. That's unusual in itself since most devs will cook up a number modules which are embedded in the GUI - all parameters included, as dynamic instruction sets.

i'm not sure what you mean with "dynamic instruction set" but to save and restore all parameters at once, we already have the top-level preset for the whole synth which load the complete synth's state from a single xml-file. i'm probably still missing your point here. are you talking about just throwing away this sub-preset functionality and leave only the top-level presets? i consider these sub-presets as a useful additional feature. the idea is to make presets for the individual sections in order to later combine them - for example load a "Supersaw" preset for the osc-section and a "Plucked" preset for the amplitude envelope to make a "Plucked Supersaw" ...or whatever. the filter is perhaps not complex enough to justify presets, but for consistency, it has that feature too. and who knows, maybe someday i complexify this filter (as an idea, i'm thinking about a dual filter with continuously adjustable serial/parallel connection and possibly more filter types/modes)

If I've got this right (and I have no synth design experience to speak of here) you chose this xml based system since it seemed more efficient.

i prefer xml over binary formats mainly for convenience, not efficiency. for one thing, it's human readable and secondly, it allows for hierarchical, tree-like organization of presets/states, which is more natural for synthesis than a flat list, like:

Code: Select all

-synth
  -osc
   -tune
   -waveform 
   -..etc.
  -filter
   -cutoff
   -resonance
  -amp-envelope
   -breakpoint1
    -time
    -value
   -breakpoint2
    -time
    -value
...etc.

If you remember, we were talking about this last year. You were thinking that you could compile sets of OSC waveform values (for example) into a much small number of xml files.

i certainly could lump a set of presets (and or sub-presets) into one file - a kind of "bank", but in the context of software synthesizers, i actually don't really see the point of the whole "bank" concept anymore. i consider this as an artifact from hardware synths. on a computer, it seems more convenient to me to use its file system to organize presets. i actually consider a folder full of preset files to *be* a "bank". doing it like this makes it easy for the user to organize and reorganize his presets as desired

...or are you talking about the waveforms themselves (as opposed to the osc-section presets). in that case, yes, i'm considering to make it possible to let each osc not just load a waveform-file but to algorithmically create it instead (as an alternative - waveform loading should still remain possible). after all, most of the waveforms in the CyclePack were created algorithmically and then stored to files at some stage. when i include the algorithms themselves into the synth, i could get rid of a lot of the CyclePack waveforms and just create them inside the synth as desired. it would also make certain parameters of the waveform continuously adjustable that are now stepped (like, for example the modulation index in the PhaseModulation... waveforms).

PS: Translation: if you're planning to roll your own GUI framework that would mean a move away from JUCE?

it's a bit to early to use the term "planning" - but considering, yes. didn't know that you are aware of how my plugins are built with JUCE, so i resorted to the generic term "GUI framework". JUCE is a great framework, but somehow i feel that it's a bit too bloated and complex for my purposes. somehow i want a leaner framework and one that is fully under my control. maybe as an intermediate step, i could move to a leaner existing framework such as SFML. i'm currently studying it, seems pretty good. and it's based on OpenGL which means that graphics-rendering would be hardware accelerated. this could be a cool thing for animated displays (like in the SignalAnalyzer) - and maybe even 3D at some stage. ...just fantasizing.

[rumba_codex]

Thanks for the reply, Robin.

"Dynamic instruction set" was a guess (or total BS) - there is another term for this ...

i'm considering to make it possible to let each osc not just load a waveform-file but to algorithmically create it instead (as an alternative - waveform loading should still remain possible). after all, most of the waveforms in the CyclePack were created algorithmically and then stored to files at some stage. when i include the algorithms themselves into the synth, i could get rid of a lot of the CyclePack waveforms and just create them inside the synth as desired. it would also make certain parameters of the waveform continuously adjustable that are now stepped (like, for example the modulation index in the PhaseModulation... waveforms).

That's it - include the algorithms themselves into the synth. That's what we were talking about before ... the word "compile" (as in bring together) then, is not out of place?

Totally understand your choice of xml ...

My basic point is to find a way to minimize file bureaucracy as much as possible (with respect to your particular design approach) but retain all the flavour.

[Music Engineer]

That's it - include the algorithms themselves into the synth. That's what we were talking about before ... the word "compile" (as in bring together) then, is not out of place?

ah OK, i see. what confused me initially was that you were talking about "OSC, Env & Filter presets". the waveforms are something that i don't really see as "presets". but i still don't understand what is wrong about the filter and envelope presets (aside from the fact there could be more such presets, and possibly better organized)

My basic point is to find a way to minimize file bureaucracy as much as possible (with respect to your particular design approach) but retain all the flavour.

"file bureaucracy" - yes, when the algorithms are included, the waveforms from the cyclepack will be needed only for very few patches. but some wavecycles can not created algorithmically because they were obtained from acoustic instrument samples - and some presets use such waveforms (for example the pianos). those would have to be there anyway, so the samples-folder will have to stay there anyway. but it could get away with much less contents then.

[rumba_codex]

Well ... to me all those xml files basically function as presets ... but that's half the problem for me - learning basic devspeak. And if you use terminology one dev understands there is no guarantee another will immediately grasp what you're trying to say. So these discussions can go off the rails a bit faster than anyone would want.

Aside from the confusion there, I think you got my point. Well, I bloody well hope so!

But I am curious about something. If you have all that acoustic instrument wavecycle data available what stops you from incorporating that into an algorithm? Is it simply too much work? Or is it a case that such an algorithm is in danger of becoming inefficient (too many variables) and therefore would contribute to a nasty CPU overhead?

Are you able to explain this in relatively simple terms? Or do you need to pop a Prozac and relax a bit after this conversation?

[Music Engineer]

Well ... to me all those xml files basically function as presets ...

yes, yes. that's the way i see it, too. but the oscillator waveforms are actually plain audio files (flac or wav)

but that's half the problem for me - learning basic devspeak.

actually, the normal user should be not supposed to learn devspeak (does s/he have to, to make sense of my software? if so, i probably should review the manuals). but yes, when talking about the internals, a little bit of that is probably unavoidable

And if you use terminology one dev understands there is no guarantee another will immediately grasp what you're trying to say.

oh yes. that is true. seems that every programmer assumes other programmers to have similar background knowledge but sometimes that isn't true

But I am curious about something. If you have all that acoustic instrument wavecycle data available what stops you from incorporating that into an algorithm? Is it simply too much work? Or is it a case that such an algorithm is in danger of becoming inefficient (too many variables) and therefore would contribute to a nasty CPU overhead?

first of all, in this context we must distinguish between the waveform creation algorithms which run in non-realtime and render the basic waveform for the oscillator. these are the algorithms that were used to render all those waveforms in the CyclePack (or most of them). then, there's the playback algorithm that transposes the waveform to the desired pitch. this must run in realtime. the playback algorithm doesn't care at all what kind of waveform it is - a waveform is a waveform is a waveform (i'm using what is called a mip-mapped wavetable oscillator - other oscillator algorithms may indeed care, just for info). so basically, the playback algorithm actually allows for acoustic instrument waveforms. in the wavefrom rendering algorithms - mmmhhh...some of them could use acoustic waveforms as well - like FMing a piano with a violin waveform or whatever. but then, the rendering algorithm would have to load waveforms and we would just have shifted the bureaucracy problem into the rendering algorithm.

Are you able to explain this in relatively simple terms? Or do you need to pop a Prozac and relax a bit after this conversation?

nah, i can still take it without colorful pills. in fact, i kinda like explaining things.

[rumba_codex]

And you are good at explaining things ... that was interesting.

Yeah, communication skills ... explaining complex ideas ... that's really a whole new discussion.

For anyone working in IT / technology (in particular, devs) it can be hard work finding the most effective way to frame your ideas - especially when you've spent years immersed in this stuff. Indeed, to paraphrase Picasso, the frame you choose can make all the difference.

[rumba_codex]

PS: Sure, referring to the actual waveforms as "presets" was absolutely not correct (apologies) - normally I would have seen that. Quite a few synths have an option to import / access 3rd party wavecycle data. But the way you've put this synth together is a little unusual (which I like, btw) , so I lumped all those files / folders together under the banner of "xml". That isn't a devspeak issue - that's pretty basic techspeak. Thanks, mate.