Forums > MaxMSP

Patching / Rerouting of sub-patches?

July 9, 2006 | 5:16 pm

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":

adc –> delay –> distortion –> dac

or

adc –> distortion –> delay –> dac

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


July 9, 2006 | 5:28 pm

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

– N.

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


July 11, 2006 | 10:18 pm

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.

Best,
Trond


July 12, 2006 | 10:28 am

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 http://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 window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 73 318 67 196617 pack 1 2 3.;
#P newex 131 277 80 196617 zmap 0 12 0. 1.;
#P newex 73 251 69 196617 unpack 1 2 3.;
#P newex 93 29 48 196617 loadbang;
#P comment 191 121 14 196617 3;
#P comment 165 121 14 196617 2;
#P comment 139 121 14 196617 1;
#P comment 117 195 14 196617 3;
#P comment 117 169 14 196617 2;
#P hidden message 109 79 72 196617 dialtracking 3;
#P hidden message 111 58 58 196617 dialmode 1;
#P user matrixctrl 137 133 83 85 FrameDialSml.jpg MatrixDefaultBkgnd.pct 83 85 26 26 3 3 26 26 1 1 1328 13 768 0;
#P window linecount 6;
#P comment 100 139 13 196617 Output;
#P window linecount 1;
#P comment 153 107 39 196617 Input;
#P comment 117 143 14 196617 1;
#P newex 333 313 68 196617 receive~ boo;
#P newex 262 313 68 196617 receive~ poo;
#P newex 191 313 67 196617 receive~ foo;
#P newex 316 447 54 196617 send~ boo;
#P newex 254 447 54 196617 send~ poo;
#P newex 192 447 56 196617 send~ foo;
#P newex 230 373 77 196617 matrix~ 3 3 0.;
#N vpatcher 20 74 620 474;
#P outlet 151 133 15 0;
#P inlet 151 84 15 0;
#P pop;
#P newobj 333 340 45 196617 p mod 3;
#N vpatcher 20 74 620 474;
#P outlet 151 133 15 0;
#P inlet 151 84 15 0;
#P pop;
#P newobj 262 340 45 196617 p mod 2;
#N vpatcher 20 74 620 474;
#P outlet 151 133 15 0;
#P inlet 151 84 15 0;
#P pop;
#P newobj 191 340 45 196617 p mod 1;
#P user panel 96 104 145 128;
#X brgb 220 247 166;
#X frgb 0 0 0;
#X border 1;
#X rounded 0;
#X shadow 0;
#X done;
#P comment 386 342 147 196617 < --- your processing modules;
#P window linecount 2;
#P comment 377 442 167 196617 send~/receive~ pairs must be used to prevent a feedback blow-up;
#P window linecount 3;
#P comment 43 393 138 196617 you might want to insert limi~’s here to control feedback;
#P window linecount 1;
#P comment 182 405 30 196617 —>;
#P fasten 18 0 27 0 142 237 78 237;
#P connect 27 0 29 0;
#P connect 27 1 29 1;
#P connect 26 0 20 0;
#P connect 26 0 19 0;
#P connect 28 0 29 2;
#P connect 27 2 28 0;
#P hidden connect 19 0 18 0;
#P hidden connect 20 0 18 0;
#P connect 12 0 5 0;
#P connect 8 0 9 0;
#P fasten 29 0 8 0 78 364 235 364;
#P connect 5 0 8 0;
#P connect 8 1 10 0;
#P connect 13 0 6 0;
#P connect 6 0 8 1;
#P connect 7 0 8 2;
#P connect 8 2 11 0;
#P connect 14 0 7 0;
#P window clipboard copycount 30;


July 12, 2006 | 12:24 pm

> #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~)

_
johan

jvkr.nl


July 13, 2006 | 3:22 pm

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
> 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.

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

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://
http://www.cassiel.com


July 13, 2006 | 5:32 pm

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

> 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!

L

Lawrence Casserley – lawrence@lcasserley.co.uk
Lawrence Electronic Operations – http://www.lcasserley.co.uk
Colourscape Music Festivals – http://www.colourscape.org.uk


July 13, 2006 | 5:53 pm

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

>> 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!

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

Thank you.

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


July 13, 2006 | 6:47 pm

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…………..

L

Lawrence Casserley – lawrence@lcasserley.co.uk
Lawrence Electronic Operations – http://www.lcasserley.co.uk
Colourscape Music Festivals – http://www.colourscape.org.uk


July 13, 2006 | 7:29 pm

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

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

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.

-Joshua


July 14, 2006 | 6:31 am

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.-)

– P.

————– 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


July 14, 2006 | 10:29 am

> Pretty opinionated.

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

> 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
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.

– N.

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


July 14, 2006 | 8:15 pm

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

>> 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.

-Joshua


July 14, 2006 | 8:43 pm

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
> 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.

-Joshua


July 15, 2006 | 8:53 am

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"
were later picked up in True BASIC & Co.

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
on Mac (cf the comments to the script on my BEK home page). How hard
would it have been to implement random() on Mac? It was like the old
days on BASIC, where it seemed that every month something changed in
the implementation (zero-based vs. one-based array indices; provision
for run-time array allocation, etc.)

Enough rumination…

————– 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


July 15, 2006 | 9:23 am

On 15 Jul 2006, at 10:53, Peter Castine wrote:

> The other thing that I find common to JScript and BASIC was the
> instability of the languages when I began either.

And the rather ad-hoc runtime type coercion.

Here’s one from JavaScript (via the phpfreaks web site) which is a
corker:

"37" – 7 // returns 30
"37" + 7 // returns 377

Rather speaks for itself, I think…

– N.

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


July 15, 2006 | 9:12 pm

On 14 juil. 06, at 22:15, Joshua Kit Clayton wrote:

> 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.

I’ll vote for that too, with an integration of pattr would be fantastic!

After playing a little bit with JavaScript, I’ll prefer Java now
also. Because, it’s as simple to write and in term of performances,
it’s so much faster than JS.

Best,
ej


July 16, 2006 | 9:59 am

all the solutions suggested work fine in a matrix of modules
which is not bigger than say 4×5.

(his original example was 1+1+1, there are like 10 easy
solutions for this task)

but as soon as you have 10×10 effect modules it is getting
damned complicated, no matter if you work with send~ or
matrix~.

a working mechanism for a 10×10 DSP module matrix is one
of my all time superstar problems.
the only solution i found which seems programmable is loading
instances of the same "distortion module" patch from disk,
but there are enough reasons left not to it this way.

one solution i sometimes use when i have 4 or 5 modules is that
i simply provide ALL POSSIBLE – OR WANTED – COMBINATIONS of
the modules as each one poly~.

it seems like it is bit of a fraud … but i believe they
did nothing else in the yamaha dx synths. :)


July 16, 2006 | 9:37 pm

On 14 Jul 2006, at 21:15, Joshua Kit Clayton wrote:

> 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.

Sounds like a plausible plan. It probably wouldn’t be a good idea to
modify your JS implementation to provide things like this (I presume
that you’re not into the idea of forking and maintaining your own JS
implementation), but some kind of client-script-compilation a la GWT
could be conceivable.

> 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.

True. And as a possible bonus (depending on one’s financial or
political geek inclination) the JavaScript would/could probably be
close to execute-only, allowing for non-source distributions. Anyway,
it’s a sweet idea, but it gives you more to maintain and keep
consistent since you’d be supporting JS as an end-user language as
well as for a toolkit compiler-to-JS.

> We’ve also considered doing things like provide an mxjui object
> which would probably be more to your liking.

That would be very sweet. I’d have to be convinced about
responsiveness due to tight user interaction crossing the JNI
boundary, but then again, I’ve written interactive graphical systems
(such as visual joystick trackers/latchers) as dual MXJ/JSUI systems
(ported from pure JSUI after problems with interrupt-level execution)
and they seem to work well enough. The whole thing would need some
intensive performance testing, but the idea of marrying a "proper" OO
language to the OpenGL world is a nice one.

On the other hand, as you said originally, a light-weight, laissez-
faire language for hacking up user interfaces also has its place,
although it can be a liability for anything nontrivial for unless one
is very careful.

> The ironic thing about the above statement is that Max itself has
> exactly these problems, being a totally dynamically typed system.

Not true – occasionally it will refuse to connect a patch cord! (I
consider that a compile-time error.)

But in Max, one is encouraged to build one’s own interactive debugger
at the same time as one is programming – a number box between two
objects, or [print]‘s at strategic locations – debugging is part and
parcel of the development process, since every incremental change in
the program is immediately live and interactive. (In this respect,
I’m reminded again of Smalltalk.)

> 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.

Indeed, and for the same reasons. One has to trust the components and
the intermediate objects, otherwise one’s confidence in their
combination is very weak.

– N.

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


July 16, 2006 | 9:41 pm

On 15 Jul 2006, at 22:12, Emmanuel Jourdan wrote:

> After playing a little bit with JavaScript, I’ll prefer Java now
> also. Because, it’s as simple to write and in term of performances,
> it’s so much faster than JS.

I’d say Java isn’t quite as simple to write… because if I’m going
for Java rather than JavaScript, it’s usually for the reason that I
want to put some proper software structure in place, and that
requires a bit of design and setup. I’ve never liked the use of Java
for quick hack-ups… which reminds me that I really should get my
MXJ port of Groovy (http://groovy.codehaus.org/) into a clean, stable
state and roll out a release…

– N.

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


Viewing 20 posts - 1 through 20 (of 20 total)