A draft whitepaper of my parameterization idea
- 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
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
- 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
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
- 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
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.
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
- 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
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.
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
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
- 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
You can call it Omnibus!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.
(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
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
- 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
OmniBus! We'll make a buzzworder out of you yet!
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:
(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).
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
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
- 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
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" ) only common practice and common sense did.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.
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
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
- 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
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: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:
(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.Code: Select all
y = e^-x
You could generalize the idea to: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.
* 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?
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
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
- 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
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: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'm not too sure I'm following you there...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).
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.dahnielson wrote:Hmm... do I smell Faust extended to handle music only with a GUI?
The editing interface would be a network editor with blocks as nodes.
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...
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.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.
Darren Landrum
- 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
Yes. I assumed that in my use cases, although implied.Consul wrote: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: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.
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.I'm not too sure I'm following you there...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).
Well, is this along the lines of what you described in the message I replied to?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.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.
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
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