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