What would be your ideal approach to modular routing ...

[avasopht]

I've not put this in feature suggestions because it's just more about your ideal interface for connecting devices, but I'm curious what is the best way to approach modular routing. You have:

1. Devices in racks, explicitly connected by wires (as seen in Reason).



Pros: a lot like real life, great for connecting devices in close proximity
Cons: complex structures can be difficult to track connections and flow, requiring meticulous investigating

2. Devices laid out like a schematic, explicitly connected by wires (as seen in Audio tool and Reaktor)



Additional variations: Reaktor allows devices to be included inside other devices, allowing for much more reusable components.
Pros: can be much easier to illustrate flow
Cons: large structures might appear much more complex than if inside a rack (not sure on this one)

3. Modulation matrix (as seen in Thor )



Pros: easy to see all connections at once
Cons: less visual; might scare away cats

4. Text files (as seen in like, nowhere ever)



Pros: uber flexible as any type of gui can be created for it, and allows for automation
Cons: gui may never be created; may scare away beginners

[tibah]

No text, rarely mod matrix for me. It's somewhere between 1 and 2. Back panel wiring has the advantage of always being separated, so you don't have to deal with it, if you don't want to. In Reaktor that stuff is also rather hidden in a deeper layer of the program. Honestly, I'm not even the guy to use Reason for flipping to the back and do stuff there. A Matrix or Synchronous is basically all I would ever need in terms of CV, or Pulverizer's ENV follower onto something. I do most things by automation or inside a synth's realm.

[rcbuse]

4. Text files (as seen in like, nowhere ever)

I would suggest looking at csound for examples of this. Csound takes this to the extreme.

[orthodox]

Never text files, they just do not fit for this task, relational database would be better.
Modulation matrix is a view of that database, it is fine until the identifiers grow so they don't fit in columns.
Both 1 and 2 should be available. Schematic should be scalable and with various focusing modes, e.g. only devices connected to the selected ones etc.

[selig]

4. Text files (as seen in like, nowhere ever)

I would suggest looking at csound for examples of this. Csound takes this to the extreme.

Ugg - takes me back to 1979 at the University of Utah, taking one of the first "computers and music" classes at the time, typing in lines of code (using an early version of sound) to simply play a sine wave - thinking: there MUST be a better way to use computers to make music…luckily, there was (5 years later)!

[swamptooth]

4. Text files (as seen in like, nowhere ever)

I would suggest looking at csound for examples of this. Csound takes this to the extreme.

Ugg - takes me back to 1979 at the University of Utah, taking one of the first "computers and music" classes at the time, typing in lines of code (using an early version of sound) to simply play a sine wave - thinking: there MUST be a better way to use computers to make music…luckily, there was (5 years later)!

Do you think the experience was valuable to your re development?

[Dante]

Ideally you should be able to view a modular hook-up in hierarchical levels (similar to how rack devices can be 'combined' using combinator)- there should be a mechanism to enable 'bundling' low level components into a device (e.g. call it a combimodule). Then at the next level up, wire together the combimodules. A this level, the subcomponents of each combimodule would be hidden until you clicked on it and then the combimodule designer would open up in a side pane.

If you modify a combimodule that's in use, then of course all instances of that combimodule in would be modified accordingly. Of course, combimodules would be available individually to other modular designs.

[selig]

4. Text files (as seen in like, nowhere ever)

I would suggest looking at csound for examples of this. Csound takes this to the extreme.

Ugg - takes me back to 1979 at the University of Utah, taking one of the first "computers and music" classes at the time, typing in lines of code (using an early version of sound) to simply play a sine wave - thinking: there MUST be a better way to use computers to make music…luckily, there was (5 years later)!

Do you think the experience was valuable to your re development?

Not directly, but definitely inspired me to pursue using computers for musical applications, something I was actually able to do a few years later first with the SSL and CMI in 1984, then with the Macintosh in 1985-6 and onward (creating the first commercial "all MIDI" direct to digital release in 1986) - never looked back ever since!

As for RE development, it would have begun with the exposure to circuit board design by my older brother (60s-70s), followed by using stuff like SoftSynth (Digidesign) in the late 1980s which showed what was potentially possible from a pure DSP angle. Also being a very early adopter of Pro Tools and mixing on it in the late 1990s inspired me to want better/different DSP based tools. Finally it would be Reaktor in the mid 2000s that REALLY got me into building custom designs and trying out some of my more wacky design concepts.

[rcbuse]

4. Text files (as seen in like, nowhere ever)

I would suggest looking at csound for examples of this. Csound takes this to the extreme.

Also, for a less extreme example, just open any RE repatch file and you can edit all parameters in plain text.

[jonheal]

Speaking as who is probably one of least accomplished and least knowledgable folks on this forum, I prefer the visual equivalent of real cables Reason offers. I lust for "real" modular stuff, but I don't have the 1,000s of dollars it would take to acquire them. Reason is the next best thing. For me, the only improvements would be be if Reason also allowed cables on the front. And maybe the option of little pop-ups that described the effect of connecting any two jacks.

Yeah the virtual cables can become a rat's nest, but have you ever watched one of Richard Divine's videos on Vimeo?

[swamptooth]

4. Text files (as seen in like, nowhere ever)

I would suggest looking at csound for examples of this. Csound takes this to the extreme.

Ugg - takes me back to 1979 at the University of Utah, taking one of the first "computers and music" classes at the time, typing in lines of code (using an early version of sound) to simply play a sine wave - thinking: there MUST be a better way to use computers to make music…luckily, there was (5 years later)!

Do you think the experience was valuable to your re development?

Not directly, but definitely inspired me to pursue using computers for musical applications, something I was actually able to do a few years later first with the SSL and CMI in 1984, then with the Macintosh in 1985-6 and onward (creating the first commercial "all MIDI" direct to digital release in 1986) - never looked back ever since!

As for RE development, it would have begun with the exposure to circuit board design by my older brother (60s-70s), followed by using stuff like SoftSynth (Digidesign) in the late 1980s which showed what was potentially possible from a pure DSP angle. Also being a very early adopter of Pro Tools and mixing on it in the late 1990s inspired me to want better/different DSP based tools. Finally it would be Reaktor in the mid 2000s that REALLY got me into building custom designs and trying out some of my more wacky design concepts.

Yeah, I totally agree. I was lucky enough to study electronic music in the early 90s at UC Santa Cruz with Peter elsea and Gordon mumma. It was really a great intro because we started splicing tape and doing music concrete stuff first so it was great to figure out what would be interesting to sample from a sound palette standpoint. If we got to advance we got our hands on a Mac with sequencer hooked up to a couple of kurzweil samplers and the granddaddy of them all a perfect Moog modular that was a beast. We also had a real early version of Max that blew my mind. Peter was all about Max. Did some csound stuff on my own and I think it helped me understand building synths from the ground up.
I actually use pure data a fair amount for experimenting with algorithms.
I agree with reaktor 100% because it's a good way to see how, say, a particular filter is modeled from a basic math perspective or the sequence of events in general DSP processing.
Have you ever contributed reaktor instruments to the ni site?

[aRiver]

There are no cons in the second view, it's superior in practical approach to the first one. If you ever had to do parallel processing within a single rack with more than 10-15 devices schematic view is a huge relief. Try to open one o the big patches, it's impossible to grasp anything without digging in, where in schematic everything is available at first glance.

[selig]

4. Text files (as seen in like, nowhere ever)

I would suggest looking at csound for examples of this. Csound takes this to the extreme.

Also, for a less extreme example, just open any RE repatch file and you can edit all parameters in plain text.

Ha, good one!

[selig]

4. Text files (as seen in like, nowhere ever)

I would suggest looking at csound for examples of this. Csound takes this to the extreme.

Ugg - takes me back to 1979 at the University of Utah, taking one of the first "computers and music" classes at the time, typing in lines of code (using an early version of sound) to simply play a sine wave - thinking: there MUST be a better way to use computers to make music…luckily, there was (5 years later)!

Do you think the experience was valuable to your re development?

Not directly, but definitely inspired me to pursue using computers for musical applications, something I was actually able to do a few years later first with the SSL and CMI in 1984, then with the Macintosh in 1985-6 and onward (creating the first commercial "all MIDI" direct to digital release in 1986) - never looked back ever since!

As for RE development, it would have begun with the exposure to circuit board design by my older brother (60s-70s), followed by using stuff like SoftSynth (Digidesign) in the late 1980s which showed what was potentially possible from a pure DSP angle. Also being a very early adopter of Pro Tools and mixing on it in the late 1990s inspired me to want better/different DSP based tools. Finally it would be Reaktor in the mid 2000s that REALLY got me into building custom designs and trying out some of my more wacky design concepts.

Yeah, I totally agree. I was lucky enough to study electronic music in the early 90s at UC Santa Cruz with Peter elsea and Gordon mumma. It was really a great intro because we started splicing tape and doing music concrete stuff first so it was great to figure out what would be interesting to sample from a sound palette standpoint. If we got to advance we got our hands on a Mac with sequencer hooked up to a couple of kurzweil samplers and the granddaddy of them all a perfect Moog modular that was a beast. We also had a real early version of Max that blew my mind. Peter was all about Max. Did some csound stuff on my own and I think it helped me understand building synths from the ground up.
I actually use pure data a fair amount for experimenting with algorithms.
I agree with reaktor 100% because it's a good way to see how, say, a particular filter is modeled from a basic math perspective or the sequence of events in general DSP processing.
Have you ever contributed reaktor instruments to the ni site?

I agree it's great to know the history of electronic music via the "hands on" approach. I would never have gotten the chance to spend time with a Moog Modular if not for another college class, but it also involved tape splicing and looping, and the history of the genre.

I never fully finished an instrument but came VERY close with the JP8000 model (couldn't figure out the feedback Osc, but otherwise built +90% including the GUI). For me the bigger lessons of Reaktor for me were not how filters are modeled but how signal flow and routing logic can take basic modules and elevate them to new levels. That's the level of development that inspires me more than the math aspect of filters (should REALLY have paid more attention in my college algebra classes…).

[orthodox]

There are no cons in the second view, it's superior in practical approach to the first one.

Not always superior. Devices with a complex set of connection points don't fit well in schematic drawings. They require custom-designed GUIs, accompanying texts and pictures. And the rack view solves this problem.

[selig]

I tend to go with the cable approach, and actually prefer the Reason "back-panel" patching paradigm which avoids clutter IMO.

But even more important to me is the method used to show the EFFECT of modulation routings. So far I like the way NI deals with this, using Massive or Kontakt as a good example.

I find the most important thing I want to know when working with a new patch (or reviewing one of my own from the past) is what is connected where, and what the effect is. Cables come closest to showing the connections (mod matrixes are probably second on my list), but in Reason there is still no good way to show the effect of any routing.

[swamptooth]

I agree it's great to know the history of electronic music via the "hands on" approach. I would never have gotten the chance to spend time with a Moog Modular if not for another college class, but it also involved tape splicing and looping, and the history of the genre.

I never fully finished an instrument but came VERY close with the JP8000 model (couldn't figure out the feedback Osc, but otherwise built +90% including the GUI). For me the bigger lessons of Reaktor for me were not how filters are modeled but how signal flow and routing logic can take basic modules and elevate them to new levels. That's the level of development that inspires me more than the math aspect of filters (should REALLY have paid more attention in my college algebra classes…).

I still have patch cable nightmares sometimes!!


http://artsites.ucsc.edu/ems/Music/equi ... /Moog.html

[selig]

I agree it's great to know the history of electronic music via the "hands on" approach. I would never have gotten the chance to spend time with a Moog Modular if not for another college class, but it also involved tape splicing and looping, and the history of the genre.

I never fully finished an instrument but came VERY close with the JP8000 model (couldn't figure out the feedback Osc, but otherwise built +90% including the GUI). For me the bigger lessons of Reaktor for me were not how filters are modeled but how signal flow and routing logic can take basic modules and elevate them to new levels. That's the level of development that inspires me more than the math aspect of filters (should REALLY have paid more attention in my college algebra classes…).

I still have patch cable nightmares sometimes!!


http://artsites.ucsc.edu/ems/Music/equi ... /Moog.html

Ha!!!

[ilikestargazing]

I've been in love with the Reason layout since the beginning. But the longer I use it, the more I wish for little, obscure changes.
I would love to be able to resize devices completely freely. I guess this would require some pretty intense re-work and vectorising of everything. I'd also love to be able to change the layout of individual devices, front and back, like adding another lfo or filter or oscillator however damn well I please, or more inputs/outputs. Of course you can do these things by adding more devices or using a merger/splitter/combinator or what have you, but the thought of it all being fully integrated per device instead is just lovely to me.

[Loque]

I like it simple, so no text files. If you have free layout, sooner or later you build groups and structure it to have a clue whats going on. The rack thing is simple, you have a good overview, some easy stuff with mod matrix, some more stuff and freedom with cables. Sometimes i whish there would be more modularity, eg Thor in pieces, but if you want to start making music, you dont want to first cable all that stuff together.

The Combinator thing brings grouping, so i can make a setup and hide everything unimportant.

Yes, for me Reason is great. In the future i hope to see unlimited mod matrix, more in and outs, and i want to exchange modules eg. changing a filter or osc within Thor by drag and drop or use just the shaper without cabling for other devices - so Reason is missing free audio routing with additional signal flow from eg. an env to a free filter. All can actually be done by most synths, but not so easy and you run into limits.

Keep it easy, but give me freedom.