A draft whitepaper of my parameterization idea

Everything and anything, but nothing about the LinuxSampler project.

Re: A draft whitepaper of my parameterization idea

Postby dahnielson » Mon Mar 31, 2008 12:42 am

Go ahead.
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
dahnielson
Moderator
 
Posts: 632
Joined: Wed Jan 23, 2008 11:25 pm
Location: Linköping / Tranås, Sweden

Re: A draft whitepaper of my parameterization idea

Postby Consul » Mon Mar 31, 2008 1:02 am

Fine. I will, then. :P ;)
Darren Landrum
User avatar
Consul
Moderator
 
Posts: 189
Joined: Wed Jan 23, 2008 11:19 pm
Location: Port Huron, Michigan, USA

Re: A draft whitepaper of my parameterization idea

Postby Consul » Mon Mar 31, 2008 2:28 am

Okay, it's sent. It was a long email, summarizing much of our brainstorming here. Normally, I'd just ask my questions, "what is this?" and "how do I do this?", but every time I do that, I always get countered with "what are you trying to accomplish?" so I thought I'd see if I could cut that middle step this time.

I don't know if you're on the FAudioStream-Devel list, but if you're not, I'll let you know the reply. I have a feeling that that for loop is not the inner loop (why use a for loop for that? It doesn't make sense to me) but is instead how they set up multichannel processing (doing the same process to two different signals in and out) with the idea that with only one channel to process, the loop will simply just happen once. I guess I'll find out if I'm right.
Darren Landrum
User avatar
Consul
Moderator
 
Posts: 189
Joined: Wed Jan 23, 2008 11:19 pm
Location: Port Huron, Michigan, USA

Re: A draft whitepaper of my parameterization idea

Postby Consul » Mon Mar 31, 2008 4:41 pm

I'm just going to quote from an email I just sent to the Faust list, to save from retyping it here:

-----

I'm actually thinking about stepping back from the idea of making a
visual programmer for the FAUST language itself, and focusing on the
routing system (Omnibus) and using FAUST to make the basic DSP blocks
separately. The focus from the beginning will be on MIDI (and possibly
OSC as well), easy polyphony management, and transparent oversampling
capability. Those are what I think a nice synth- and sampler-building
application needs. The fact that it'll also be able to make other kinds
of plug-ins, by allowing external audio streams in, is a nice side-effect.

-----

My thinking is that this plan will get us from A to B a lot faster, the only price being having to code FAUST blocks manually. A visual programmer for FAUST can always be pursued later as a companion application.
Darren Landrum
User avatar
Consul
Moderator
 
Posts: 189
Joined: Wed Jan 23, 2008 11:19 pm
Location: Port Huron, Michigan, USA

Re: A draft whitepaper of my parameterization idea

Postby dahnielson » Mon Mar 31, 2008 4:49 pm

Yes. That probably wise. FAUST is the expression you type into Omnibus "blocks" (when you're not using prefabs). Omnibus handling the routing of signals between the blocks. Yet again, I haven't acquired any deeper understanding of FAUST yet (have other IRL stuff I need to get out of the way first).
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
dahnielson
Moderator
 
Posts: 632
Joined: Wed Jan 23, 2008 11:25 pm
Location: Linköping / Tranås, Sweden

Re: A draft whitepaper of my parameterization idea

Postby Consul » Mon Mar 31, 2008 5:47 pm

No worries. I'll just keep doing what I'm doing and when I get stuck, I'll ask questions. Thank you for your help, and for being interested in this project.
Darren Landrum
User avatar
Consul
Moderator
 
Posts: 189
Joined: Wed Jan 23, 2008 11:19 pm
Location: Port Huron, Michigan, USA

Re: A draft whitepaper of my parameterization idea

Postby Consul » Tue Apr 01, 2008 2:52 am

Well, I'm finding out that explaining this project and its goals is a lot more difficult than I first though. One thing a professor of mine always says is, "you never know if you truly understand something until you try to explain it to someone else." I'm hoping my latest email has explained it a little better. For naming purposes, I called the entire application Nuklear, which I think will serve just fine as an "internal code name" until we think of something better. The routing layer is Omnibus, and the processing functions are called Blocks.
Darren Landrum
User avatar
Consul
Moderator
 
Posts: 189
Joined: Wed Jan 23, 2008 11:19 pm
Location: Port Huron, Michigan, USA

Re: A draft whitepaper of my parameterization idea

Postby Consul » Tue Apr 01, 2008 4:08 pm

You know what would also be a great feature? The ability for two or more people to collaborate on the creation of an instrument. It doesn't need to be anything on the level of CVS, just a few features to make collective synth-building run smoothly. That way, more complex projects, like our big sampler, can be worked on by more than one person.

I wouldn't think this would be too hard to do if all of our instrument definitions are in XML files.
Darren Landrum
User avatar
Consul
Moderator
 
Posts: 189
Joined: Wed Jan 23, 2008 11:19 pm
Location: Port Huron, Michigan, USA

Re: A draft whitepaper of my parameterization idea

Postby Consul » Tue Apr 01, 2008 5:07 pm

Some other ideas:

We'll need to design our blocks to report back to Omnibus the following information:

Name
Input(s)
Output(s)
Range and curve for each input
Range and curve for each output
Is It a Control or Signal Input or Output?

This way, Omnibus can be more intelligent when making connections. For connection to a control input, for example, if Omnibus knows the output range of the block connecting to the input, which it also knows the range of, it can automatically apply scaling to the connection of a control input, which can be overridden by the user, of course. For audio ports, no scaling will be done by default unless, again, the user wants it. The scaling curve can also be automatically determined and changed, as desired.

From an interface standpoint, instead of creating blocks for the scaling and oversampling functions, they should be a part of the connection itself. Hover over a connection, and you'll see all kinds of information about what it's doing, and what data is going through it. You can then right click to add, remove, or change anything. So, to oversample one or more blocks, the connection to the first block will be set to upsample, then the connection out of the final block will simply downsample by the same amount. Left-clicking will allow you to reroute the connection. Up- and down-sampling connections can also be made a different color (or other visual property) so they stand out.

As for what can be seen from hovering over, well, the sky's the limit. Numerical data, an oscilloscope view, a spectral view, all sorts of fun stuff can be done.
Darren Landrum
User avatar
Consul
Moderator
 
Posts: 189
Joined: Wed Jan 23, 2008 11:19 pm
Location: Port Huron, Michigan, USA

Re: A draft whitepaper of my parameterization idea

Postby Consul » Wed Apr 02, 2008 5:54 am

Yup, the for() loop on the inside is how FAUST handles multiple inputs and outputs for each block. Now it's just a question of how do we access the parameters of the function from the outside. I'll take the code into my C++ prof tomorrow and see if he can help me make sense of it.
Darren Landrum
User avatar
Consul
Moderator
 
Posts: 189
Joined: Wed Jan 23, 2008 11:19 pm
Location: Port Huron, Michigan, USA

PreviousNext

Return to 100% Project Unrelated

Who is online

Users browsing this forum: No registered users and 0 guests

cron