Quadratic Equation

I'm working on a set of signal processing modules in a patch, all of which lie in parallel. I'm trying to think of a way to combine these modules so that they lie in series, but also so that the order can be rearranged. At the moment I have this:

http://img293.imageshack.us/img293/2429/untitled0ie.png

This is all well and good, but unfortunately the signals are just being mixed; I would like to achieve a series combination where, for instance, the delayed signal could be distorted, or vice verse depending on how the overall patch is "routed":

What kind of techniques or patch elements would faciliate this kind of construction?

patching-rerouting-of-sub-patches

You could bung the ins and outs through a matrix~ running in binary 

mode, and then use the node settings to reorder the effects.

nick rothwell -- composition, systems, performance -- 

You could bung the ins and outs through a matrix~ running in binary  
mode, and then use the node settings to reorder the effects.

   nick rothwell -- composition, systems, performance -- http:// 
www.cassiel.com


Another possibility would be to use send~ and receive~ for audio in and 

out of each module, and then dynamically change the sequence of the 

modules using "set" messages to send~ and receive~. I don't know if this 

would be more or less CPU consuming than a matrix~, so you should 

probably run some tests to see how they compare. One disadvantage of the 

send~/receive~ approach is that each send~/receive~ pair will delay the 

signal by one signal vector. If you have several modules, this could 

Another possibility would be to use send~ and receive~ for audio in and 
out of each module, and then dynamically change the sequence of the 
modules using "set" messages to send~ and receive~. I don't know if this 
would be more or less CPU consuming than a matrix~, so you should 
probably run some tests to see how they compare. One disadvantage of the 
send~/receive~ approach is that each send~/receive~ pair will delay the 
signal by one signal vector. If you have several modules, this could 
become a noticeable latency.

Matrix~ is indeed your friend, but why stop at binary mode? Using a matrixctrl in the secret Ninja dial mode, you can save youself some objects/space, and sample the joys of controlled feedback.

I posted a feedback matrix that does this for Leafcutter John's Framework project a while back; unfortunately, the only version of Framework that's available now (on the C74/share pages) predates this version, but a simplified version of the routing/feedback patch, without the scripting, is below, and the graphic for it (FrameDialSml.jpg) is at www.wildfrontear.co.uk/mctl stuff.1.zip - put this .jpg somewhere in Max's search path before opening the patch.

(to open the patch, copy the text below and selct New From Clipboard in Max)

Matrix~ is indeed your friend, but why stop at binary mode? Using a matrixctrl in the secret Ninja dial mode, you can save youself some objects/space, and sample the joys of controlled feedback.
 I posted a feedback matrix that does this for Leafcutter John's Framework project a while back; unfortunately, the only version of Framework that's available now (on the C74/share pages) predates this version, but a simplified version of the routing/feedback patch, without the scripting, is below, and the graphic for it (FrameDialSml.jpg) is at www.wildfrontear.co.uk/mctl stuff.1.zip - put this .jpg somewhere in Max's search path before opening the patch.
(to open the patch, copy the text below and selct New From Clipboard in Max)
cheers
Roger

> #P comment 377 442 167 196617 send~/receive~ pairs must be used to prevent a feedback blow-up

If the introduced delay is unacceptable, there is a possibility to achieve what is required using poly~. Imagine each voice of a poly has a different content (a different transformation). Mute all voices that are not required, allowing the sound only to pass through the voice that contains the transformation you want. A series of such poly~s allow to make the chain of transformations desired. Loading different patches in each voice is done (within the patch that poly~ will hold) by scripted instantiation of a bpatcher that loads a unique patch (using thispoly~)

On 12 Jul 2006, at 12:28, roger.carruthers wrote:

> Using a matrixctrl in the secret Ninja dial mode, you can save 

> youself some objects/space, and sample the joys of controlled 

That's rather sweet, and if I'd seen the message a few days earlier I 

might have saved myself some effort in my own, rather over-engineered 

(by comparison) effort: a JSUI-based mixing matrix UI which

- is resizable, with auto-scaling and variable numbers of ins and outs

- shows numerical dB gain/attenuation on any knob that's dragged to a 

- changes the knobs' colours to act as a VU level matrix

- is pattr-aware and uses "scribble strip" association lists of names 

for ins and outs so that the matrix topology can be changed/reordered 

without messing up existing pattrstorage entries

It's just a control system for matrix~, and the VU meters take a 

strobed feed of levels as a floating-point list assembled from 

It is quite a lot (800+ lines) of JavaScript...

Screen dump enclosed. I hope I can roll out some kind of release of 

> Using a matrixctrl in the secret Ninja dial mode, you can save  
> youself some objects/space, and sample the joys of controlled  
> feedback.

That's rather sweet, and if I'd seen the message a few days earlier I  
might have saved myself some effort in my own, rather over-engineered  
(by comparison) effort: a JSUI-based mixing matrix UI which

- is resizable, with auto-scaling and variable numbers of ins and outs
- shows numerical dB gain/attenuation on any knob that's dragged to a  
new setting (not with Nixies, alas)
- changes the knobs' colours to act as a VU level matrix
- is pattr-aware and uses "scribble strip" association lists of names  
for ins and outs so that the matrix topology can be changed/reordered  
without messing up existing pattrstorage entries

It's just a control system for matrix~, and the VU meters take a  
strobed feed of levels as a floating-point list assembled from  
peakamp~ instances.

Screen dump enclosed. I hope I can roll out some kind of release of  
this over the next few days.

   nick rothwell -- composition, systems, performance -- http:// 
www.cassiel.com

On 13 Jul 2006, at 16:22, Nick Rothwell wrote:

> Screen dump enclosed. I hope I can roll out some kind of release of 

Lawrence Casserley - lawrence@lcasserley.co.uk

Lawrence Electronic Operations - www.lcasserley.co.uk

Colourscape Music Festivals - www.colourscape.org.uk

> Screen dump enclosed. I hope I can roll out some kind of release of  
> this over the next few days.

Lawrence Casserley - lawrence@lcasserley.co.uk
Lawrence Electronic Operations - www.lcasserley.co.uk
Colourscape Music Festivals - www.colourscape.org.uk


On 13 Jul 2006, at 19:32, lawrence casserley wrote:

>> Screen dump enclosed. I hope I can roll out some kind of release 

I'd just like to say that I think JavaScript is a godawful language.

>> Screen dump enclosed. I hope I can roll out some kind of release  
>> of this over the next few days.
>
> Yes - I'd like to see that one!

On 13 Jul 2006, at 18:53, Nick Rothwell wrote:

> I'd just like to say that I think JavaScript is a godawful language.

I took one look and ran away screaming - but then I'm not really a 

programmer at all - I did a lot of machine code in the old days, but 

that worked because I could make a good mental image of the chip I 

was using, and the code simply manipulated that image - funnily 

enough, I see Max a bit like that - I can make clear mental images of 

what is going on, and the patch reflects that. These text languages 

just don't seem to represent my way of thinking, although I did get 

on well with BCPL in those days, but that was so close to machine 

code that I was comfortable - ah, those were the days..............

I took one look and ran away screaming - but then I'm not really a  
programmer at all - I did a lot of machine code in the old days, but  
that worked because I could make a good mental image of the chip I  
was using, and the code simply manipulated that image - funnily  
enough, I see Max a bit like that - I can make clear mental images of  
what is going on, and the patch reflects that. These text languages  
just don't seem to represent my way of thinking, although I did get  
on well with BCPL in those days, but that was so close to machine  
code that I was comfortable - ah, those were the days..............

On Jul 13, 2006, at 10:53 AM, Nick Rothwell wrote:

Pretty opinionated. Just out of curiosity, what specifically do you 

dislike? Is it the language itself (specifically the lack of static 

typing for catching problems at compile time), or is it the lack of 

integrated syntax checking, and source code debugging or just runtime 

performance? The latter elements aren't really the language per se.

Aside from the weak dynamic binding strategy (which make problems 

difficult to catch until runtime), I personally enjoy programming in 

JS. Very smalltalky and flexible, and fairly "max-like". FWIW, there 

are some extensions proposed for optional strict typing (as checked 

by a syntax checking editor), and ActionScript uses them. e.g. 

function foo(Number:v) {};, but this isn't Javascript 1.5 compliant. 

Pretty opinionated. Just out of curiosity, what specifically do you  
dislike? Is it the language itself (specifically the lack of static  
typing for catching problems at compile time), or is it the lack of  
integrated syntax checking, and source code debugging or just runtime  
performance? The latter elements aren't really the language per se.

Aside from the weak dynamic binding strategy (which make problems  
difficult to catch until runtime), I personally enjoy programming in  
JS. Very smalltalky and flexible, and fairly "max-like". FWIW, there  
are some extensions proposed for optional strict typing (as checked  
by a syntax checking editor), and ActionScript uses them. e.g.  
function foo(Number:v) {};, but this isn't Javascript 1.5 compliant.  
I believe it's in JS 2.0.

On 13-Jul-2006, at 21:29, Joshua Kit Clayton wrote:

> what specifically do you dislike? Is it the language itself 

> (specifically the lack of static typing for catching problems at 

> compile time), or is it the lack of integrated syntax checking, and 

> source code debugging or just runtime performance?

I can't answer for Nick, but there's something about JScript that 

reminds me of programming BASIC, and whatever it is, it leaves me 

But there are a lot of subjective elements in the way people react to 

different PLs. "Subjective" doesn't mean "invalid" but can mean "take 

with a grain of salt". In some cases that grain may weigh several 

metric tons (as witnessed by another thread on the list.-)

Peter Castine +--> Litter Power & Litter Bundle for Jitter

Interface Building for |home | chez nous|

Max/MSP Extremely cool |bei uns | i nostri|

On 13-Jul-2006, at 21:29, Joshua Kit Clayton wrote:
> what specifically do you dislike? Is it the language itself  
> (specifically the lack of static typing for catching problems at  
> compile time), or is it the lack of integrated syntax checking, and  
> source code debugging or just runtime performance?

I can't answer for Nick, but there's something about JScript that  
reminds me of programming BASIC, and whatever it is, it leaves me  
uncomfortable with the language.

But there are a lot of subjective elements in the way people react to  
different PLs. "Subjective" doesn't mean "invalid" but can mean "take  
with a grain of salt". In some cases that grain may weigh several  
metric tons (as witnessed by another thread on the list.-)

--------------    http://www.bek.no/~pcastine/Litter/    -------------
Peter Castine             +--> Litter Power & Litter Bundle for Jitter
                                Universal Binaries on the way
iCE:  Sequencing,  Recording &
       Interface  Building  for                   |home    | chez nous|
       Max/MSP   Extremely cool                   |bei uns |  i nostri|
       http://www.dspaudio.com/                   http://www.castine.de

When it comes to discussing programming languages, I thought that was 

> Just out of curiosity, what specifically do you dislike?

Well, firstly I'll say what I like. JavaScript is nice and simple, 

and I like the open-ended object model where eveerything has 

properties which can be tagged on arbitrarily, and having object 

literals is nice too. The basic library is pretty useable as well. 

I've got one or two niggles about things like implicit type 

No particular complaints about JavaScript-to-OpenGL model either: 

it's pretty elegant and easy to use (although I do wish that the C- 

side data for Sketches and Images wasn't so huge - I can easily chew 

up 1Gb of virtual memory reloading my mixing matrix when I don't get 

the chance to do all the freepeer() calls first).

What I most certainly don't like is the totally dynamic typing (and, 

worse, dynamic name resolution): a simple typo in an identifier name 

will result in a program which compiles but fails mysteriously with a 

"property not found" message at some line unrelated to the location 

of the error. I once accidentally typed something like foo[x] instead 

of foo(x) and, again, the program loaded fine but misbehaved in 

mysterious ways. I thought computers were supposed to deal with this 

Certainly, it's useful to have a lightweight and flexible language 

for prototyping things (depending on what's being prototyped: 

sometimes semantic rigour is more important than brevity), but I 

think a typeless language only works in the presence of a good run- 

time debugger (such as in Smalltalk), and (by and large) only for 

small and/or highly modular software systems; doing major stuff in 

JavaScript under Max is an exercise in care, and in rolling one's own 

prettyprinting code. My usual approach when using JSUI is to regard 

it as a simple rendering engine and do all the heavy lifting in Java.

When it comes to discussing programming languages, I thought that was  
pretty much a tradition...

Well, firstly I'll say what I like. JavaScript is nice and simple,  
and I like the open-ended object model where eveerything has  
properties which can be tagged on arbitrarily, and having object  
literals is nice too. The basic library is pretty useable as well.  
I've got one or two niggles about things like implicit type  
conversion, but nothing major.

No particular complaints about JavaScript-to-OpenGL model either:  
it's pretty elegant and easy to use (although I do wish that the C- 
side data for Sketches and Images wasn't so huge - I can easily chew  
up 1Gb of virtual memory reloading my mixing matrix when I don't get  
the chance to do all the freepeer() calls first).

What I most certainly don't like is the totally dynamic typing (and,  
worse, dynamic name resolution): a simple typo in an identifier name  
will result in a program which compiles but fails mysteriously with a  
"property not found" message at some line unrelated to the location  
of the error. I once accidentally typed something like foo[x] instead  
of foo(x) and, again, the program loaded fine but misbehaved in  
mysterious ways. I thought computers were supposed to deal with this  
stuff for us?

Certainly, it's useful to have a lightweight and flexible language  
for prototyping things (depending on what's being prototyped:  
sometimes semantic rigour is more important than brevity), but I  
think a typeless language only works in the presence of a good run- 
time debugger (such as in Smalltalk), and (by and large) only for  
small and/or highly modular software systems; doing major stuff in  
JavaScript under Max is an exercise in care, and in rolling one's own  
prettyprinting code. My usual approach when using JSUI is to regard  
it as a simple rendering engine and do all the heavy lifting in Java.

On Jul 14, 2006, at 3:29 AM, Nick Rothwell wrote:

> When it comes to discussing programming languages, I thought that 

Ja. However, the more I program, the less I care about the language. 

It would be nice to find a decent JS editor which would do some 

syntax checking and warn about things like mistyped variable names, 

or obvious misusage of objects in situations which can be detected 

while editing. Perhaps this is something we can investigate doing to 

make JS programming in Max less cumbersome for large projects. 

Macromedia's done some good work in this area for ActionScript in 

Flash and JS in DreamWeaver, and some of the new AJAX tools seem 

promising as well. Similar to what Google Web Toolkit and others have 

done, one could imagine for people familiar with Java, a set of proxy 

classes for JSUI development, which could under go Java strict typing 

and compilation, and if successful, translate the source file to JS. 

It wouldn't be that difficult to write such a program to translate 

the output. We've also considered doing things like provide an mxjui 

object which would probably be more to your liking. Just throwing out 

some ideas, not committing to anything/anytime, but this feedback is 

> What I most certainly don't like is the totally dynamic typing 

> (and, worse, dynamic name resolution): a simple typo in an 

> identifier name will result in a program which compiles but fails 

> mysteriously with a "property not found" message at some line 

> unrelated to the location of the error. I once accidentally typed 

> something like foo[x] instead of foo(x) and, again, the program 

> loaded fine but misbehaved in mysterious ways. I thought computers 

> were supposed to deal with this stuff for us?

The ironic thing about the above statement is that Max itself has 

exactly these problems, being a totally dynamically typed system. 

However perhaps the expectations in a text based programming language 

are different given the compilers and editors most of us are using. 

Or perhaps it's just that the program is more visual, and can be more 

easily modified while running to easier track down the problems, 

though large scale projects can be just as difficult to debug in my 

>> Pretty opinionated.
>
> When it comes to discussing programming languages, I thought that  
> was pretty much a tradition...

Ja. However, the more I program, the less I care about the language.  
It would be nice to find a decent JS editor which would do some  
syntax checking and warn about things like mistyped variable names,  
or obvious misusage of objects in situations which can be detected  
while editing. Perhaps this is something we can investigate doing to  
make JS programming in Max less cumbersome for large projects.  
Macromedia's done some good work in this area for ActionScript in  
Flash and JS in DreamWeaver, and some of the new AJAX tools seem  
promising as well. Similar to what Google Web Toolkit and others have  
done, one could imagine for people familiar with Java, a set of proxy  
classes for JSUI development, which could under go Java strict typing  
and compilation, and if successful, translate the source file to JS.  
It wouldn't be that difficult to write such a program to translate  
the output. We've also considered doing things like provide an mxjui  
object which would probably be more to your liking. Just throwing out  
some ideas, not committing to anything/anytime, but this feedback is  
important for us to hear.

> What I most certainly don't like is the totally dynamic typing  
> (and, worse, dynamic name resolution): a simple typo in an  
> identifier name will result in a program which compiles but fails  
> mysteriously with a "property not found" message at some line  
> unrelated to the location of the error. I once accidentally typed  
> something like foo[x] instead of foo(x) and, again, the program  
> loaded fine but misbehaved in mysterious ways. I thought computers  
> were supposed to deal with this stuff for us?

The ironic thing about the above statement is that Max itself has  
exactly these problems, being a totally dynamically typed system.  
However perhaps the expectations in a text based programming language  
are different given the compilers and editors most of us are using.  
Or perhaps it's just that the program is more visual, and can be more  
easily modified while running to easier track down the problems,  
though large scale projects can be just as difficult to debug in my  
experience.

On Jul 13, 2006, at 11:31 PM, Peter Castine wrote:

> I can't answer for Nick, but there's something about JScript that 

> reminds me of programming BASIC, and whatever it is, it leaves me 

Curious. I wonder what that is. Maybe it has more psychological 

roots. I don't see very many similarities between BASIC and 

JavaScript aside from the similarities that are common to programming 

languages in general. However, BASIC's a pretty cool language too. I 

have fond memories of being 10 years old programming basic on 

Commodore PET, then TRS-80, then Apple II. This might reinforce the 

idea of psychological attachment/aversion to languages.

> I can't answer for Nick, but there's something about JScript that  
> reminds me of programming BASIC, and whatever it is, it leaves me  
> uncomfortable with the language.

Curious. I wonder what that is. Maybe it has more psychological  
roots. I don't see very many similarities between BASIC and  
JavaScript aside from the similarities that are common to programming  
languages in general. However, BASIC's a pretty cool language too. I  
have fond memories of being 10 years old programming basic on  
Commodore PET, then TRS-80, then Apple II. This might reinforce the  
idea of psychological attachment/aversion to languages.

There is certainly psychology involved (but isn't there always?).

I suppose the biggest similarity between BASIC and JavaScript is 

target audience. The languages were designed to be easy to learn and 

accessible to people without prior software development experience.

While I, too, have fond memories of programming BASIC on a PDP-8 and 

before that a time-sharing system lost in the mists of time (accessed 

from a teletype w/dial-up 75bps acoustic modem), it encouraged 

numerous truly bad programming habits that I had to break later. By 

the time I came back to the language (on a PET, btw: we have that 

much in common) I was able to avoid most of the programming pitfalls 

(although lack of local variables was still a trap). I think the 

first BASIC that was usable as a learning language was the BBC Basic 

that came on the Acorn B. The extensions introduced with "the Beeb" 

The other thing that I find common to JScript and BASIC was the 

instability of the languages when I began either. When I started 

JavaScript, there were functions implemented on Unix that didn't work 

Patching / Rerouting of sub-patches?