Patching / Rerouting of sub-patches?


    Jul 09 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:
    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?

    • Jul 09 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:// www.cassiel.com
    • Jul 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
    • Jul 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 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
    • Jul 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
    • Jul 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:// www.cassiel.com
    • Jul 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 - www.lcasserley.co.uk Colourscape Music Festivals - www.colourscape.org.uk
    • Jul 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:// www.cassiel.com
    • Jul 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 - www.lcasserley.co.uk Colourscape Music Festivals - www.colourscape.org.uk
    • Jul 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
    • Jul 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
    • Jul 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:// www.cassiel.com
    • Jul 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
    • Jul 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
    • Jul 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
    • Jul 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:// www.cassiel.com
    • Jul 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
    • Jul 16 2006 | 9:59 am
      all the solutions suggested work fine in a matrix of modules which is not bigger than say 4x5.
      (his original example was 1+1+1, there are like 10 easy solutions for this task)
      but as soon as you have 10x10 effect modules it is getting damned complicated, no matter if you work with send~ or matrix~.
      a working mechanism for a 10x10 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. :)
    • Jul 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:// www.cassiel.com
    • Jul 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:// www.cassiel.com