Moselle, a new software synth, nearing release

DSP, Plugin and Host development discussion.

Whats your reaction to this sample program?

I can't even look at it much less understand it.
5
21%
I could figure it out with time and the manual.. but won't.
13
54%
I get it but it'd be easier to read if it were programmed in <name of synth software>. (Tell me what software and share a screenshot if you have time.)
0
No votes
Its as clear to me as it'd be with any other system I've used, even with zero Moselle experience.
1
4%
Its Patching Nirvana! Do not sleep, Frank, until you have delivered a working binary to me!
5
21%
 
Total votes: 24

RELATED
PRODUCTS

Post

Moselle is both a textual synth language, and a (currently Windows, currently stand-alone) program that can be programmed with it.

(Moselle is kind of an acronym for "Modular Synthesizer Language.")

I'll have a first, free, "proof of concept" release in the next couple of months. Hence, my interest in starting to talk about it a little bit to gauge interest, get some feedback, hear about similar systems and so on.

I'll be going into more specifics later, and happy to talk about the system ad infinitum. But as teasers, here's 1) a collection of screenshots and 2) a current running patch for you to take a look at if you're interested.

This sample patch is only a dozen lines or so, but programs an audio oscillator (Osc1) undergoing FM-modulation, AM-modulation, AND a frequency hard-sync from a controlling Osc2. Output then goes into a filter, digital delay. The output is not only heard, but seen on-screen on an oscilloscope.

https://www.facebook.com/frank.sheeran/ ... 772&type=3

---------------------------------------------------------------------------

[Osc1]
Frequency = Voice:Frequency * ( 1 + (GeneralPurpose2 +.1)*10 * Env1:Control * ( 1.1 - Osc2:Control ) )
Waveform = Square
Duty = Velocity / 2
SyncIn = Osc2:SyncOut

[Osc2]
Frequency = Voice:Frequency
Waveform = Sawtooth

[Env1]
Decay = .8

[Env2]
Decay = .05
Sustain = .6

[Filter]
Input = Env2:Audio * Osc1:Control* ((Osc2:Control+1)/2)^ (GeneralPurpose3^.5)
Cutoff = 300 + 2000 * Velocity + ModulationWheel * 10000
Resonance = 10
Poles = 2

[Delay]
Input = Filter:Audio
Time1 = .425

[Voice]
Mono = Delay:Output

[Scope]
Probe1 = Voice:Mono
Start = Osc2:SyncOut
Stop = Osc2:SyncOut

Post

From this example it looks like your essentially just connecting a few high-level modules, so I wonder: why textural representation instead of a graphical interface? Does it go beyond patch definitions? Can you go down to a lower level, like build your own filters or different oscillator algorithms? Do you provide some particularly powerful abstractions?

If your purpose is to build a modular synth of some sort, then a more graphical approach would probably make it significantly easier to use. If you're aiming to provide more powerful programming possibilities, then maybe you could post some such example?

Can't really judge what's on your Facebook page because.. well.. it doesn't work without Facebook account, and I got rid of mine years ago. Sorry.

Post

Development Diary for 13 June 2013.

For the first time, sound modules that are "per patch" not "per voice" are working. In other words, no matter how many notes you're playing at once, all the notes are affected by a single module.

The first thing I got working was a per-patch LFO. Until today your only choice was LFO's for each note. Roll on a chord note by note, and some LFO's would be going down while others go up, etc. In fact that's often what you want (perhaps simulating a string quartet?), but not always (Hammond simulation?).

The second thing was a per-patch digital delay. The normal use of echo is such that even when a note ends, the echoes continue on. Until today, the Delay modules were part of your note. When the note ended, the echoes abruptly ended too. It was actually a cool effect I can't remember having heard before (though it doubtless existed). But now you can choose normal as well.

As a variation on that, you might apply EQ (Moselle doesn't have EQ yet but will) to your entire sound. To the listener, or even engineer and musician, you can't hear whether each voice has its own EQ or whether they're all sharing a single EQ. However, the computer has a lot more work to do with this relatively expensive calculation if it has to do seven separate EQ calculations for seven separate notes. That's a waste of power, which may well matter if your computer isn't powerful enough to play seven notes simultaneously when they each have individual EQ's.

-------

While I was working on supporting per-patch modules I had to break the Oscilloscope and the "All Sound Off" MIDI function... I have to get those working again... I need to look into why varying the speed of the Delay doesn't quite work for longer echoes. Then I need to go back to Stored Waveform Oscillator (basically a band-limited oscillator with additional features) and figure out why it sounds worse than the non-band-limited "naive math" oscillator.

Post

Hi Mystran,

Thx for taking a moment for feedback.
mystran wrote:From this example it looks like your essentially just connecting a few high-level modules, so I wonder: why textural representation instead of a graphical interface?
There are about 3 families of graphical interface I can think of, but I don't know how any of them can show all the detail this textual patch does. Perhaps I could turn that around, and ask if you can supply me with a diagram that holds this amount of data, in some format that is both easier for the writer to write and easier for a subsequent reader to read?

Specifically, I'd like to see a picture that actually holds the same information as the Osc1 Frequency equation (whereby that frequency is modified by Osc2's output, but at an amount that is controlled by both an envelope and a MIDI controller?

I'd really love to be proven wrong on this but right now I'm pessimistic that it is possible. The reason is computer history.

In the 1950's computers were programmed with switches and patch cords. Computer power was growing quickly, and soon the limit to things you could compute wasn't the power of the computer, but the amount of time it'd take to patch a program together. Textual computer languages were developed in the 1950s and took over programming. In the subsequent half-century, there have been 1000's of proposals for graphical programming languages for computers. And in a field where people are spending over a trillion dollars a year, they'd love to have a simpler easier alternative (inter alia, so that more people could do the work and they could hire cheaper people). But despite all the people who'd love a cheaper, easier way to program computers, no visual language has caught on.

In the same way, I get the feeling that a lot of the synths today are making sounds they could have on a computer from 1995. Despite the computer being about 500x more powerful, most soft synths still give you pictures of patch cords, knobs and switches.

The main reason I started working on Moselle is as an experiment: to see whether a textual language would be as big a benefit to programming synth sounds, as they've been for programming computers.
mystran wrote:Does it go beyond patch definitions? Can you go down to a lower level, like build your own filters or different oscillator algorithms? Do you provide some particularly powerful abstractions?
No, it goes neither down into building components, nor up into building compositions and so on. Its conceivable that module types could be hot-pluggable: for instance if you wrote a new filter (in C++, with the right interfaces) it is imaginable it could be used from Moselle.
mystran wrote:Can't really judge what's on your Facebook page because.. well.. it doesn't work without Facebook account, and I got rid of mine years ago. Sorry.
I didn't realize that. I'll find a different way.

Post

Hey, I'm all for textual language where they provide abstractive power that is inconvenient in graphical systems. I'm a component Unix admin, have my own Lisp dialect (debugging garbage collectors is kinda fun), etc.. so it's not like I'm afraid of textual code.. but what I wanted to know was just that: what abstractive power does your language have that is inconvenient to implement in a graphical system?

Post

mystran wrote:Hey, I'm all for textual language where they provide abstractive power that is inconvenient in graphical systems. I'm a component Unix admin, have my own Lisp dialect (debugging garbage collectors is kinda fun), etc.. so it's not like I'm afraid of textual code.. but what I wanted to know was just that: what abstractive power does your language have that is inconvenient to implement in a graphical system?
Thanks again Mystran.

My hypothesis (and I don't consider this a fact, rather its the idea that I want to prove or disprove with Moselle) is not that text is more powerful than a graphical system, but that it is more information-dense, easier to write, and easier to read.

To be exact, I think "easy" things, eg VCO->VCF->VCA (with Env also going into VCA) might be easier in a graphical system, but the difficulty of easy things isn't what limits us. I think once the task starts approaching "medium difficulty" the text will pull way ahead on ease of writing and reading.

For an example, I'd like to take the Filter's Input parameter from my example above.

Code: Select all

[Filter]
Input = Env2:Audio * Osc1:Control* ((Osc2:Control+1)/2)^ (GeneralPurpose3^.5) 
While the general jist is probably clear to you, some details will make it 100% clear.

Moselle represents most numbers on a [0..1] or [-1..1] basis. Osc2 is a sawtooth. It has several outputs. One is "Audio", and scales amplitude down as pitch goes up (keeping volume, typically, the same). However here, I'm using the "Control" output. That ranges from -1 to 1 (or since the sawtooth is descending, 1 to -1) no matter what the frequency. Therefore ((Osc2:Control+1)/2) ranges from (1+1)/2 to (-1+1)/2, in other words 1 to 0. In short, by the time Osc2 gets to the end of its waveform, the filter input will have been AM-modulated to nothing.

The MIDI controllers are also all mapped to [0..1] or [-1..1]. Since ((Osc2:Control+1)/2) ranges from [0..1], raising it to any power will also go from [0..1] but with a different curve. In this case a power above 1 would "suck the curve down" while below 1 would "puff the curve up." The AM-mod always starts the waveform at 100% and ends at 0%. However in between, turning the GeneralPurpose3 knob on your MIDI controller to the left makes the AM go to 0 rather quickly, while turning it to the right makes the AM stay strong until you get near the end of the waveform.

While playing with this, I noticed that the audible change was much more drastic at one end of the control. Raising it to a power of ^.5 experimentally gave what felt like a smoother control. It doesn't change the range of sounds available in the least; it just changes what knob position gives you what sound.

Finally, multiplying that whole mess by Env1's Audio output (which is logarithmic) simply gives it a normal volume envelope. Rather than a specific "VCO" component, this multiplication does the job.

-------------------

OK, so my question still stands. I personally can't really think of a way to make a "photorealistic" GUI (eg knobs and patchcords) that contains all the information of that equation. Even with a "photorealistic" picture of a modular synth, I can see dragging cords from the Env1, Osc2, and MIDI inputs, but I don't see how I could then do the math.

On a "schematic" GUI (like Max/MSP) I can at least think of a way to specify that exact equation, but the way I'm thinking of would look sort of like a "parse tree" of Moselle's internal representation of that formula. In other words I can see the input of the filter being a box labeled "multiply". The "multiply" box would have Env1's output as one input, and a second input from Osc1. Assuming "multiply" could have >2 inputs, the third would come from a "power of" box. Powerof's first input would be Osc1, second input would be the output of another "power of." Et cetera... While I can see A way to do it, this way doesn't sound easier for a patch writer to write. It also doesn't sound easier for someone to read later.

Do you think I'm wrong? Do you think such a tree would really be easier to write and read? Or do you think there's some seriously better way to make a "schematic" GUI that contains the same relationships?

(I mentioned earlier that I could think of three types of GUI. The third type of GUI would not contain all the information on the diagram, but instead serve as a high-level representation showing what's connected to what. So you'd see a simple box diagram of Osc1 and Env1 going into a Filter, going into a delay, going to the output. To get more detail about exactly how these modules interact you'd have to "drill down" into the diagram to see individual params. However those individual params would again be text. So to me, its not so much a Graphic Programming Language, but more of a "visual index." So this "representation" doesn't have the defining power of a language. But even then, how would you show the role of Osc2? How can you show it is doing FM-modulation, AM-modulation, and Hard Sync on Osc1? Would the software figure out there is some connection, draw a line, and leave it to the user to label it or not?

Post

Well, you could also use traditional GUI with some sort of modulation matrix that had something similar to FL's Formula Contoller.

If you're not familiar, then the thing is essentially a plugin that gives you 3 knobs (and some constants like songtime.. note that the "knobs" themselves can be automated from other sources) and then lets you write mathematical expressions to define what the output should be. The output then is a "control signal" which can be assigned to any parameter that allows automation (including VST parameters) the same way you'd map MIDI controllers or whatever.. although FL also allows you to write formulas in control assignments (if you just want to change the curve), so if you wanted to assign a MIDI control with sqrt-taper and inverted to a VST parameter, you'd just set the mapping to "1-sqrt(Input)" in the assignment (or something, I forgot the details of the exact syntax).

If you're not familiar, I'd really check it out. Being able to refer to the time (either real or song) means you can use it to write simple LFOs and such. It's all control signal level, but if you did something similar in a plugin, there's no reason you couldn't do such a thing at audio rates as well. :)

Another example of a somewhat related thing is rs-met "Func Shaper" which is a waveshaper plugin that lets you write a mathematical function, which it then uses to process the audio (the screenshot on Robin's page actually has an example of "tanh(a*x)" where "a" is a parameter on the plugin GUI and x is the audio signal). Again you could build something like this directly into a more complex plugin, for us when you need the extra flexibility.

Observe that both plugins (FuncShaper and FL Formula Controller) also give you instant visual feedback on your expressions, so you can visually validate that you got what you wanted. I don't know if you should do such a thing, but my point is that it's certainly possible to do hybrid schemes where the "simple stuff" is available in a simple graphical interface, while things like advanced modulation can still benefit from being able to write down a complex formula.

Post

Swiss Frank wrote:This sample patch is only a dozen lines or so
About three dozen lines, and far from self-explaining, especially where it comes to defining and connecting the various parts. I don't mean to sound negative here; it's just that without an accompanying manual, I couldn't even begin to understand what's possible to realize with your textual description, and how.
"Until you spread your wings, you'll have no idea how far you can walk." Image

Post

Cool, it looks really interesting :)

Could you maybe explain how you see it differing from say Csound or perhaps where Moselle's specific advantages are?

Post

Swiss Frank wrote:To be exact, I think "easy" things, eg VCO->VCF->VCA (with Env also going into VCA) might be easier in a graphical system, but the difficulty of easy things isn't what limits us. I think once the task starts approaching "medium difficulty" the text will pull way ahead on ease of writing and reading.
How will it pull ahead?
Graphical systems self-parse. There's no mispelled variables, no semantic or lexical errors that can be introduced by the user. System-nonsensical connections (like feedback loops, or control-rate->data-rate connections) can be prevented. Your textual system needs to user to engage in a 'write-compile-test' loop to ensure that your 'code' works, something that a graphical system manages automatically. Especially existing graphical systems like MAX/MSP and PureData which actually generate text files 'under the hood' defining those connections. Overall, versus graphical systems, thats a loss in terms of 'ease of writing', not a gain.
As for 'ease of reading', I'd argue that a direct visual representation of a complex signal flow is far easier to read than an abstracted textual one, where one would basically have to build and keep a mental map of the connections to get an overview of any signal path beyond the simplest possibilities. I mean, humans are toolbuilders, we're used to hooking up things to each other and understanding how they interact from 'sight'; hence the proclivity of things like flowcharts and UML for managing textual software construction. Machines parse (and generate) textual data well, but actually, we dont tend to.

Thing is, Im sure you know that there already are existing textual audio programming languages, like CSound and Supercollider. However, to me, it appears like you're trying to embrace the part of audio programming that's actually best done graphically, whilst dropping all the stuff that text-based languages are actually incredibly powerful at, eg that spectrum from low-level instrument design, through to interactive/generative scoring...

From the rest of your post, it sounds like you cant imaging 'photorealistic' UI elements for math elements (why photorealistic, btw, I thought we were merely talking 'graphical?'). Given that analogue modular synths were heavily derived from analogue computers I'm not entirely sure why you'd think that was a problem. Which mathematical functions (that are applicable to audio signals) do you think arent calculable in the analog realm? Isnt there something somewhat ironic about replicating an analog-originated structure with text on the basis that you dont know what analog elements would provide the same results?
my other modular synth is a bugbrand

Post

mystran: also, SynthEdit can be an example, it has this WaveShaper2 module where you basically write a math expression like tanh(x*pi) and it evaluates it, "x" being your input signal, you also get the function plotted on a display

it would be nice if you could have such a modular environment with both visual and textual representation of the same thing, because most times it's easier to understand what's going on when you see how it's connected visually, while sometimes it's easier to work with text (like select a whole block and copy/delete it)
It doesn't matter how it sounds..
..as long as it has BASS and it's LOUD!

irc.libera.chat >>> #kvr

Post

Swiss Frank wrote: My hypothesis (and I don't consider this a fact, rather its the idea that I want to prove or disprove with Moselle) is not that text is more powerful than a graphical system, but that it is more information-dense, easier to write, and easier to read.
I'm definitely also a text guy (and therefore find your project really interesting), but I don't think that this is something you could "prove", especially in general. What people find easy to write or read depends on their mindset. And I have the impression, that the minority has a preference for textural representations. But please continue with your project, for sure you will an audience if it is well done (but to get me as part of your audience, it must run as VST plugin). I worked a lot with Reaktor in the past, but doing math via drawing lines is in my eyes really a strange concept, especially when you are used to it just to type a formula. And DSP is a lot about math.
Swiss Frank wrote:No, it goes neither down into building components, nor up into building compositions and so on.
When you care about the easiness to write and read information, you must tackle the composition issue. E.g. look at the complex Max screenshot on your facebook account. It is really a mess, but mostly because the same structure is copied eight times. But copying the same text 8 times isn't a much better solution.

Post

mystran wrote:Well, you could also use traditional GUI with some sort of modulation matrix that had something similar to FL's Formula Contoller.
I spent about 10 minutes looking at vids for this, but while the formula part I get, I'm not sure I understand the appeal of the GUI side. Maybe I need to learn more about it, or try using it.
mystran wrote:It's all control signal level, but if you did something similar in a plugin, there's no reason you couldn't do such a thing at audio rates as well.
Moselle's been "doing it" at audio rates since 2010 8-) Albeit not integrated into a DAW.

Depending on the interest of the free standalone "research" version, putting it into a plug-in would be the next step. (It'd also need a lot of performance improvement and need to be ported to Apple, so fair warning, that might have to be a commercial system.)
mystran wrote:Another example of a somewhat related thing is rs-met "Func Shaper" which is a waveshaper plugin that lets you write a mathematical function, which it then uses to process the audio (the screenshot on Robin's page actually has an example of "tanh(a*x)" where "a" is a parameter on the plugin GUI and x is the audio signal). Again you could build something like this directly into a more complex plugin, for us when you need the extra flexibility.
I do stuff like that on Moselle a lot (its probably even more important when writing and debugging the synth than when using it!). If you see the bottom of my sample patch above, there's an "Oscilloscope" module that takes up to 8 probes. Just add "Probe2 = Osc1:Frequency" and you'll see a graph of how the FM is changing the frequency of Osc1 as the Osc2 goes through 360 degrees. To see the AM, add "Probe 3 = ((Osc2:Control+1)/2)^ (GeneralPurpose3^.5)." Hold down a note and wiggle the GP3 knob. If you don't like the response curve, maybe change .5 to .8 and hit F5 to recompile. (Compile's instant.)

(I just remembered you can't see the screen shots. I haven't figured out how to upload to KVR yet.)
mystran wrote:I don't know if you should do such a thing, but my point is that it's certainly possible to do hybrid schemes where the "simple stuff" is available in a simple graphical interface, while things like advanced modulation can still benefit from being able to write down a complex formula.
My priority is to make HARD jobs easier. Even if it makes easy jobs a little harder, heck, by definition easy things aren't a problem. I'm lazy. I'd rather hit a button with a picture of a sawtooth than type the word "sawtooth." But typing the word doesn't block my project. In contrast many graphical synths seem to make EASY jobs easier, medium jobs difficult, and difficult jobs impossible.

That said, I actually agree such things would be must-haves.

I do have some graphics ideas, specifically editors for modules whose data doesn't change in real time (esp. EQ, the shape of a Map (can be used as waveshaper, response curve, alternate tuning), a harmonic spectrum or a "draw your own waveform" for the stored-waveform oscillator, etc.) I've thought about a graphical envelope editor. The problem with that is that editors are great for a "cast in stone" shapes, whereas I'd like to see practically every segment in an envelope be fluid, responding to MIDI controllers, keyboard tracking, perhaps even random numbers and so on.

On the other hand, my project is set: to prove or disprove the hypothesis that a TEXT-based editor makes it easier to write and read substantial patches. I don't really have the freedom to set that aside and start adding more graphics before its even released 8-)

BTW I've found all your comments quite interesting, and its impressive you have so much knowledge about current offerings at your fingertips.

Post

Swiss Frank wrote:(I just remembered you can't see the screen shots. I haven't figured out how to upload to KVR yet.)
Its not possible; KVR doesnt host files, you'll need to have them somewhere else. The BBCode IMG tag will embed offsite images in your post, though.
my other modular synth is a bugbrand

Post

arakula wrote:
Swiss Frank wrote:This sample patch is only a dozen lines or so
About three dozen lines, and far from self-explaining, especially where it comes to defining and connecting the various parts. I don't mean to sound negative here; it's just that without an accompanying manual, I couldn't even begin to understand what's possible to realize with your textual description, and how.
Arakula, thanks for taking a look. In fact, after writing "a dozen lines or so" I actually changed to a completely different, and far more difficult example. Maybe subconciously I was thinking that a "simple" sound would probably be easier on a fixed-routing synth, and thus not be a good example of what I was aiming for. Instead I picked an example that would be quite difficult on most graphical synths but of course many people won't even be familiar with AM modulation or hard sync these days, and the FM modulation isn't anything like traditional Yamaha FM.

So I take blame for an overly-complex example, but I also take to heart your explanation that something that is "clear" to me may not be clear to other people. After all I've been working on it four years...

I don't know if these would help at all but two ways to increase clarity a little bit:

One of the benefits of a text language is the ability to put explanatory comments everywhere. You can do that in some graphical synths (the only Max/MSP patches I can follow have as much text devoted to comments as Moselle has to write the patch), but for some reason I actually took the comments out of the patch I shared. (I think I planned on adding enough description in the mail text.)

One of the changes I have in mind is to be able to label quantities' units: rather than "Gain = .5" it should be clearer to write "Gain = -3dB". Rather than "Freqency = Osc1:Frequency * 2^(1/12)" it'd be clearer to say "Frequency = Osc1:Frequency + 1 semi". I plan on supporting keywords octave, semi, cent, and dB. Technically its interesting in that they're "exponential" constants: adding 1 octave actually means to multiply by 2. Adding 2 octaves means multiply by 4. Adding 3 octaves means multiply by 8, and so on. Many of the other inputs, for instance envelope times, are in units of seconds. I aim to allow you to write "Attack = .8 sec" or "Attack = 800ms" I don't know if that would begin to help readability much.

Post Reply

Return to “DSP and Plugin Development”