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 » Mon Mar 24, 2008 12:15 pm

I've just suddenly realized here that what I've been doing this entire time is developing an idea centering around the use of DSP for control signals. This might allow me to step back and refine some ideas.
Darren Landrum

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 » Tue Mar 25, 2008 5:34 am

I'm just gonna say, "treat control signals the same as audio signals and allow DSP to work on them as well" and be done with it for now. I want to get back to my guitar amp simulator project. No more drafts for a while, if ever.
Darren Landrum

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 » Wed Mar 26, 2008 3:58 pm

I want to get something off of my chest.

I put a lot of work into this paper, trying to solve problems with the logic of making this work. When I finally start posting drafts, all I get is feedback on the paper, and none on the actual ideas, which is what's really important. If you think they're bad ideas, say so. It won't hurt my feelings. What bothers me is these ideas simply being ignored or overlooked.

Let's see some real discussion for a change.
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 » Wed Mar 26, 2008 5:19 pm

Will comment on it tomorrow when I'm less deprived of sleep. But my comment on the paper was to help you communicating your ideas efficiently and make discussion easier. Diagrams kicks ass. :D
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
Contact:

Re: A draft whitepaper of my parameterization idea

Post by dahnielson » Wed Mar 26, 2008 5:27 pm

Consul wrote:I'm just gonna say, "treat control signals the same as audio signals and allow DSP to work on them as well" and be done with it for now. I want to get back to my guitar amp simulator project. No more drafts for a while, if ever.
You can call it Omnibus! :D

(Seriously, I need to get some sleep.)
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 » Wed Mar 26, 2008 6:52 pm

OmniBus! We'll make a buzzworder out of you yet! :D

If I can finally get some discussion on the ideas themselves going, allow me to be my own worst critic for a minute: throw out most everything written in the current draft of the paper, and let's start from these basic ideas:

1) Control signals are just like audio signals, run at the same rates, can be patched in the same way, and can be processed in the same way.
2) The DSP blocks to create and process control signals should be as atomic as possible, to allow for them to be used together both serially, in parallel, and recursively, so we can create complex new features out of simpler ones.
3) New DSP blocks (for control or audio) should be easy to code and integrate into the whole, if not by the sound designer, then at least by any programmer.
4) The parameters of the new DSP block should be accessible by the GUI and open to control from outside signals.

One idea for a DSP block would be a transfer function, with one input and one output, wherein the transfer function itself could be defined by a scripting language. For example, I could open a transfer function block and type in something like:

Code: Select all

y = e^-x
(That makes a falling exponential curve, right?) The input can be a timer, and the output will be a value that can then go on to control something else.

Another DSP block would be a signal scaler, where a signal input is scaled to fit a different range. Yet another block could be a continuous function to stepped output, using a table as the function. The opposite of that, stepped input to continuous output, would create a lag function, which is essential to many sound designs.

My CS teacher warned me about trying to make functions too atomic. The way I was heading (trying to make one neat thing do it all) would essentially require sound designers to become C++ coders. The whole idea was to avoid that, so a DCSP (Digital Control Signal Processing :) ) paradigm might work a lot better and get the same results (creating new features of the sampler as part of the sound design process).
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 » Wed Mar 26, 2008 7:13 pm

Consul wrote:1) Control signals are just like audio signals, run at the same rates, can be patched in the same way, and can be processed in the same way.
Historic precursor: From my understanding the original modular Moogs didn't really make a difference between audio and control signal, it's up to the programmer (a.k.a "the guy who painstakingly patch everything together with cords" :D ) only common practice and common sense did.
Last edited by dahnielson on Thu Mar 27, 2008 7:34 pm, edited 1 time 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
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 » Wed Mar 26, 2008 7:33 pm

Consul wrote:One idea for a DSP block would be a transfer function, with one input and one output, wherein the transfer function itself could be defined by a scripting language. For example, I could open a transfer function block and type in something like:

Code: Select all

y = e^-x
(That makes a falling exponential curve, right?) The input can be a timer, and the output will be a value that can then go on to control something else.
What would represent the input in the block syntax? I assume y could be implied as output by assignment or should there be named outputs (the y itself implies an output in all transfer function blocks)? I assume the later.
Consul wrote:Another DSP block would be a signal scaler, where a signal input is scaled to fit a different range. Yet another block could be a continuous function to stepped output, using a table as the function. The opposite of that, stepped input to continuous output, would create a lag function, which is essential to many sound designs.
You could generalize the idea to:

* A generalization of blocks: blocks is to be connected together, but empty and without defined I/Os by default.
* A realized block: has a defined set of I/Os, contain a function (an expression) doing something with the I/Os.
* The I/Os would be untyped, or rather, a single type (a discreet signal).

Hmm... do I smell Faust extended to handle music only with a GUI? :D

The editing interface would be a network editor with blocks as nodes.

Use case #1:
* Add a ready-made block to the worksheet.
* Connect its I/Os to other blocks already in the worksheet.

Use case #2:
* Add a blank block to the worksheet.
* Activate editing of the block:
** Set I/Os, the number and their labels
** Define an expression doing something with the I/Os
* End block editing
* Connect its I/Os to other blocks already in the worksheet

The expressions are expressed in a DSP language with a standard function library.
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 » Thu Mar 27, 2008 1:57 am

dahnielson wrote:What would represent the input in the block syntax? I assume y could be implied as output by assignment or should there be named outputs (the y itself implies an output in all transfer function blocks)? I assume the later.
I simply used x and y for convenience. Those are the typical variables for the input and output variables of a mathematical function. The actual variable names chosen could be anything, really.
dahnielson wrote:You could generalize the idea to:

* A generalization of blocks: blocks is to be connected together, but empty and without defined I/Os by default.
* A realized block: has a defined set of I/Os, contain a function (an expression) doing something with the I/Os.
* The I/Os would be untyped, or rather, a single type (a discreet signal).
I'm not too sure I'm following you there...
dahnielson wrote:Hmm... do I smell Faust extended to handle music only with a GUI? :D

The editing interface would be a network editor with blocks as nodes.
FAUST has been integrated into CLAM and its own Network Editor. They don't yet have integrated MIDI though, so it can't really make synths yet.

Nevertheless, I actually have looked into the idea of using Dave Robillard's Flowcanvas as a GUI for creating FAUST functions and linking them together. I don't know if I really have the skill to pull that off, though. If you want to try to attack it together...
dahnielson wrote:Use case #1:
* Add a ready-made block to the worksheet.
* Connect its I/Os to other blocks already in the worksheet.

Use case #2:
* Add a blank block to the worksheet.
* Activate editing of the block:
** Set I/Os, the number and their labels
** Define an expression doing something with the I/Os
* End block editing
* Connect its I/Os to other blocks already in the worksheet

The expressions are expressed in a DSP language with a standard function library.
I do have to admit, I like the idea of an open source Reaktor on steroids. :) Although that might be a great goal for a different project, I think it might fall outside the scope of a new sampler. Still, if you want to pursue a design, I'm game.
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 » Thu Mar 27, 2008 2:06 am

Consul wrote:
dahnielson wrote:What would represent the input in the block syntax? I assume y could be implied as output by assignment or should there be named outputs (the y itself implies an output in all transfer function blocks)? I assume the later.
I simply used x and y for convenience. Those are the typical variables for the input and output variables of a mathematical function. The actual variable names chosen could be anything, really.
Yes. I assumed that in my use cases, although implied.
dahnielson wrote:You could generalize the idea to:

* A generalization of blocks: blocks is to be connected together, but empty and without defined I/Os by default.
* A realized block: has a defined set of I/Os, contain a function (an expression) doing something with the I/Os.
* The I/Os would be untyped, or rather, a single type (a discreet signal).
I'm not too sure I'm following you there...
See the use cases as example for the generalization/realization of blocks. The last bullet point is analog to my previous Moog example but in a discreet domain.
dahnielson wrote:Use case #1:
* Add a ready-made block to the worksheet.
* Connect its I/Os to other blocks already in the worksheet.

Use case #2:
* Add a blank block to the worksheet.
* Activate editing of the block:
** Set I/Os, the number and their labels
** Define an expression doing something with the I/Os
* End block editing
* Connect its I/Os to other blocks already in the worksheet

The expressions are expressed in a DSP language with a standard function library.
I do have to admit, I like the idea of an open source Reaktor on steroids. :) Although that might be a great goal for a different project, I think it might fall outside the scope of a new sampler. Still, if you want to pursue a design, I'm game.
Well, is this along the lines of what you described in the message I replied to?
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