A draft whitepaper of my parameterization idea

Everything and anything, but nothing about the LinuxSampler project.
User avatar
Consul
Moderator
Posts: 189
Joined: Wed Jan 23, 2008 11:19 pm
Location: Port Huron, Michigan, USA
Contact:

Re: A draft whitepaper of my parameterization idea

Post by Consul » Sat Mar 29, 2008 10:02 pm

Or do we really want to go that route? Would it be possible to build something that is basically a visual programmer for FAUST? That already has all of the good stuff in it. We'd just need to integrate the output of the FAUST and GCC compilers into an Omnibus network in some fashion.

On the other hand, we have the Spice-Like Way, which would work by mathematically describing the components that can make up a circuit or sub-circuit (a block) and then compiling it using all of those methods we've already discussed. I think I've already said how much I like this idea, as it is something that has not been done. It could be the ultimate open-source Reaktor, where the core is descriptions of components, rather than adders, delay lines, and all that fun stuff. Of course, adders and delays would still be in there, just described in a different fashion.

Or are these two ideas really the same idea wearing different hats? I don't know anymore. We've gone so far into left field I've forgotten what we set out to do in the first place.
Darren Landrum

User avatar
dahnielson
Moderator
Posts: 632
Joined: Wed Jan 23, 2008 11:25 pm
Location: Linköping / Tranås, Sweden
Contact:

Re: A draft whitepaper of my parameterization idea

Post by dahnielson » Sat Mar 29, 2008 10:36 pm

Consul wrote:Or do we really want to go that route?
The recursive bit was what I hinted at with "integrated circuit" as you might have guessed. ;)
Consul wrote:Would it be possible to build something that is basically a visual programmer for FAUST? That already has all of the good stuff in it. We'd just need to integrate the output of the FAUST and GCC compilers into an Omnibus network in some fashion.
I would rather go with the VLP for FAUST idea. Argh... need to get me soaked in FAUST soon so I can discuss that route with more authoritey!! :D Or more seriously, how to add new bits and pieces to FAUST. But regarding the output all we need to do is write a new template (there's already one for JACK, another for LADSPA and so on) afaik.
Consul wrote:Or are these two ideas really the same idea wearing different hats? I don't know anymore. We've gone so far into left field I've forgotten what we set out to do in the first place.
I'd say they're more alike than different.

The code generated by a visual programmer can just as well be coded manually.
Anders Dahnielson

Ardour2, Qtractor, Linuxsampler, M-AUDIO Delta 1010, Axiom 61, Korg D12, AKAI S2000, E-MU Proteus 2k, Roland R-5, Roland HP 1300e, Zoom RFX-1000, 4GB RAM x86_64 Intel Pentium Dual 1.80GHz Gentoo Linux

User avatar
Consul
Moderator
Posts: 189
Joined: Wed Jan 23, 2008 11:19 pm
Location: Port Huron, Michigan, USA
Contact:

Re: A draft whitepaper of my parameterization idea

Post by Consul » Sat Mar 29, 2008 11:08 pm

dahnielson wrote:Argh... need to get me soaked in FAUST soon so I can discuss that route with more authoritey!! :D
Heh, just do what I do and fake it all. Beyond some basic DSP programming, I haven't done anything other than read papers and books and study some math. Up until now, I haven't had a project I really wanted to sink my teeth into. Another sine wave oscillator? Done it. Another EQ? Whatever. A guitar amp sim and a new sampler with whole new paradigms? Now we're talking. An all-in-one music DSP application system? Now that's a project!

FAUST can compile an SVG block diagram of its own code. Surely we can make that work in reverse. The FAUST papers and tutorials talk about drawing out your block diagrams before coding your program. How about drawing out block diagrams which are coding your program?

It would be a good place to start.
Darren Landrum

User avatar
dahnielson
Moderator
Posts: 632
Joined: Wed Jan 23, 2008 11:25 pm
Location: Linköping / Tranås, Sweden
Contact:

Re: A draft whitepaper of my parameterization idea

Post by dahnielson » Sun Mar 30, 2008 1:31 am

Need to grok FAUST code... :x

BTW, took a look at the faust-0.9.9.3/tools/faust2pd-1.0.2/examples/synth directory, there's some synths written in FAUST in there using Pd for audio and MIDI I/O. So wrapping Omnibus around FAUST with MIDI I/O shouldn't be that hard. Guess that's how we're going to get Rubber Band et al. into the mix as well unless it's entirely reimplemented in FAUST (need to find out if it's possible to link and use non-FAUST APIs from FAUST as extensions).

My proposal is to create an LV2 "architecture" for FAUST, let Omnibus be an LV2 host and load compiled VIs as LV2 plugins (in addition to authoring them in a visual programming environment for FAUST that is).

What I like about this project is the possible sleekness of the editors in addition to the powers given authors of virtual instruments.
Last edited by dahnielson on Sun Mar 30, 2008 1:50 am, edited 2 times in total.
Anders Dahnielson

Ardour2, Qtractor, Linuxsampler, M-AUDIO Delta 1010, Axiom 61, Korg D12, AKAI S2000, E-MU Proteus 2k, Roland R-5, Roland HP 1300e, Zoom RFX-1000, 4GB RAM x86_64 Intel Pentium Dual 1.80GHz Gentoo Linux

User avatar
Consul
Moderator
Posts: 189
Joined: Wed Jan 23, 2008 11:19 pm
Location: Port Huron, Michigan, USA
Contact:

Re: A draft whitepaper of my parameterization idea

Post by Consul » Sun Mar 30, 2008 1:38 am

Well, the LV2 spec doesn't seem to have anything against an LV2 plug-in hosting further LV2 plugs. That kind of recursive plug-in architecture has always been something of an unreliable hack in the VST world. That way, Omnibus could host LV2 plugs as part of another LV2 plug. See what I'm getting at? Of course, Omnibus could also be a JACK client.

This paper, which I'm reading now, will help you out quite a bit with the logic and design underlying FAUST: http://www.grame.fr/pub/faust-icmc2002.pdf
Darren Landrum

User avatar
dahnielson
Moderator
Posts: 632
Joined: Wed Jan 23, 2008 11:25 pm
Location: Linköping / Tranås, Sweden
Contact:

Re: A draft whitepaper of my parameterization idea

Post by dahnielson » Sun Mar 30, 2008 1:44 am

Consul wrote:Well, the LV2 spec doesn't seem to have anything against an LV2 plug-in hosting further LV2 plugs. That kind of recursive plug-in architecture has always been something of an unreliable hack in the VST world. That way, Omnibus could host LV2 plugs as part of another LV2 plug. See what I'm getting at? Of course, Omnibus could also be a JACK client.
Yes. But my thinking was that Omnibus created VIs get compiled into LV2s and can either be:
  1. Loaded, used (generate or process sound) and edited from within the Omnibus application; or
  2. Loaded and used (generate or process sound) by any LV2 host.
Of course, we can also make the Omnibus application available as an LV2 plugin that will load, use and edit the LV2 VIs (I assume that's what you meant).
Anders Dahnielson

Ardour2, Qtractor, Linuxsampler, M-AUDIO Delta 1010, Axiom 61, Korg D12, AKAI S2000, E-MU Proteus 2k, Roland R-5, Roland HP 1300e, Zoom RFX-1000, 4GB RAM x86_64 Intel Pentium Dual 1.80GHz Gentoo Linux

User avatar
Consul
Moderator
Posts: 189
Joined: Wed Jan 23, 2008 11:19 pm
Location: Port Huron, Michigan, USA
Contact:

Re: A draft whitepaper of my parameterization idea

Post by Consul » Sun Mar 30, 2008 1:51 am

Well, no I'm thinking more in terms of including binary LV2s in an Omnibus synth which then itself gets compiled as an LV2. It's recursive, you see. I think, though, that the LV2 spec can handle that.

We're going to need a new name for Omnibus. Back when it was just the name of the routing system, it was okay, but now that we're using it as the name for a synth and sampler construction kit, there's definitely going to be trademark conflict with Omnisphere, whether there should be or not.
Darren Landrum

User avatar
dahnielson
Moderator
Posts: 632
Joined: Wed Jan 23, 2008 11:25 pm
Location: Linköping / Tranås, Sweden
Contact:

Re: A draft whitepaper of my parameterization idea

Post by dahnielson » Sun Mar 30, 2008 2:17 am

Yes, but recursion will then become a run-time behavior (and not a compile time, the reason we settled for FAUST). I'm not sure about having LV2s loading LV2s, since our LV2s will be written in FAUST except for any outer Omnibus-host (of course it's possible somehow by creating and RDF extension to define outside of the FAUST code what LV2s that a particular LV2 use and need to be loaded). It will become complicated and far from the simplest thing that can possibly work. I'm much happier with just having a LV2 compiled from FAUST with the *.dsp file generated by the visual programming editor.

Any suggestion for a new name?

PS. I just realized that I lost an hour of the night due to the change to summer time. Dang! :x
PPS. But my neighbors are still quite loud so I won't get any sleep if I went to bed anyway.
Anders Dahnielson

Ardour2, Qtractor, Linuxsampler, M-AUDIO Delta 1010, Axiom 61, Korg D12, AKAI S2000, E-MU Proteus 2k, Roland R-5, Roland HP 1300e, Zoom RFX-1000, 4GB RAM x86_64 Intel Pentium Dual 1.80GHz Gentoo Linux

User avatar
Consul
Moderator
Posts: 189
Joined: Wed Jan 23, 2008 11:19 pm
Location: Port Huron, Michigan, USA
Contact:

Re: A draft whitepaper of my parameterization idea

Post by Consul » Sun Mar 30, 2008 2:31 am

I'm tempted to take the piss out of Native Instruments and call it Nuklear, but that's too obvious. :D

Well, we keep throwing about words like "atomic" and "element"... How about "Dmitri", after Dmitri Mendeleyev, the inventor of the Periodic Table? Or maybe we can just call it "Atomic". Or "Atomik" if we still want to take the piss out of NI. :mrgreen:

EDIT: Blargh. Atomik is taken. http://www.alphaworks.ibm.com/tech/atomik

Any other ideas?

ANOTHER EDIT: We can also play on the word "element." No C to turn into a K, though. :D Maybe "Elemental"?

I just found something called "Sylphs" which are air elementals in Greek mythology. http://en.wikipedia.org/wiki/Sylph

YET ANOTHER EDIT: I just saw a reference to a proper name "Sylvestris." I like that name!
Darren Landrum

User avatar
dahnielson
Moderator
Posts: 632
Joined: Wed Jan 23, 2008 11:25 pm
Location: Linköping / Tranås, Sweden
Contact:

Re: A draft whitepaper of my parameterization idea

Post by dahnielson » Sun Mar 30, 2008 2:37 am

"The most important thing in the programming language is the name. A language will not succeed without a good name. I have recently invented a very good name and now I am looking for a suitable language." -- Donal E. Knuth
Anders Dahnielson

Ardour2, Qtractor, Linuxsampler, M-AUDIO Delta 1010, Axiom 61, Korg D12, AKAI S2000, E-MU Proteus 2k, Roland R-5, Roland HP 1300e, Zoom RFX-1000, 4GB RAM x86_64 Intel Pentium Dual 1.80GHz Gentoo Linux

Post Reply