Max/MSP

[packrat]

You can organise a patch poorly or well, complicated things, particularly involving complex sequencing (emptying buffer before starting to write to it again etc) are a complete prick in Max.

 

Merely incrementing numbers and generating simple sequences is much more of a pain than it should be. Same with labview. Lovely to shunt data around, crap at complex control stuff.

 

B>

[packrat]

Oh yes, and before I forget. Moving chunks of code around when you're adding a new feature to a complex patch becomes a real pig when you have to reroute wires/connections all over the place. going the otherway, going overboard with send/receive elements really isn't a solution to this.

 

B>

[kooki_sf]

1) its not complicated. its a function of one of the most basic objects in max, trigger, or "t". its the backbone of GL patches in max. clearing before writing buffers is dead simple.

 

2)encapsulation. its easy. it works. its not messy. its FAST.

[XorAxAx]

I gotta agree with you, packrat. One of my profs back in CS school was very much into graphical programming, so I saw a fair amount of LabView "code". It looked like it would have been a right pain to refactor or otherwise maintain. For instance, how do you search-and-replace in a graphical editor?

[urbanscallywag]

I gotta agree with you, packrat. One of my profs back in CS school was very much into graphical programming, so I saw a fair amount of LabView "code". It looked like it would have been a right pain to refactor or otherwise maintain. For instance, how do you search-and-replace in a graphical editor?

I use Simulink/MATLAB at school which has a MAX/MSP-ish interface to it.

If you want to use a constant maybe gain for example, in 10 different places, you use a variable x. In the MATLAB window (command line) you can type x=3; If that value is no good try x=2; It will change each instance of x in the graphical interface. Now you've got a work around for search and replace.

[urbanscallywag]

I'd agree with that. Why anyone in their right mind would want to use their whole brain wiring together simple iteration and similar code in a graphical editor, having to fret about the precise sequence of signal outputs etc, when they could just write in a sane imperative language is beyond me. Max/MSP is very nice for some signal flow things, but no matter what way you slice it, trying to program control logic into something like Max or LabView is a waste of everyone involved's time. And that's ignore the horror when you come to try to change it. B>

There are instances where a schematic is better than code.

 

I would never want to do a PCB schematic with code. You can though. Same with SPICE simulations, why use text for something that is graphical?

 

In digital design it can be easier to tie various modules of VHDL code together with a graphical interface rather than port map them in a text file.

 

Now that I think about it you're pointing out the shortcomings of person->computer interaction. A mouse is slow and can only be in one place at one time. Your brain is running much faster than a mouse could keep up with. Seems like 10 fingers on a keyboard can get information into a computer much faster, though its far from an ideal solution I think.

[XorAxAx]

Seems like 10 fingers on a keyboard can get information into a computer much faster, though its far from an ideal solution I think.

 

The ideal interface is a neural one. But we gotta figure out security before we go anywhere near a neural interface, lest some enterprising dude hack into my brain and stop my heart.

[urbanscallywag]

The ideal interface is a neural one. But we gotta figure out security before we go anywhere near a neural interface, lest some enterprising dude hack into my brain and stop my heart.

Jah I know! Der neural networks vill be veird!

[girevik]

1) its not complicated. its a function of one of the most basic objects in max, trigger, or "t". its the backbone of GL patches in max. clearing before writing buffers is dead simple. 2)encapsulation. its easy. it works. its not messy. its FAST.

 

 

Exactly. Max/MSP will let you wrap up your patch into one object (encapsulation), which you can then patch into other objects, then wrap all of THAT up into yet another object (encapsulation) if you want.

 

Unfed's initial post was misleading, unfortunately, though I'm sure that was not intentional on his part. People use Max/MSP for the visual aspect - there are many other options if you'd rather write source code.

[packrat]

And again, while you can encapsulate things, if you need a non-trivial interaction between two encapsulated things you're in a world of pain. Syncynronising a single buffer is easy, yes, double, partially sampled buffers with disk IO suddenly becomes much less so.

 

Yes, I know Max/MSP is lovely and fluffy for signal processing stuff. I've said so multiple times. The problem comes about when you want to do complicated control processing and end up futzing about with zillions of horrible little wires.

 

Simulink over Matlab is a great counterexample becuase you do actually have access to both paradigms.

 

And finally, I've done data acquisiton work in LabView, Matlab and C, I'm more than fully aware of the benefits and drawbacks to each. Anyone claiming that a graphical interface can do everything you need is on crack.

 

B>

[urbanscallywag]

Hope I never said graphics are all you need. They certainly help though.

[urbanscallywag]

My ultimate point was that code is that code is not very artistic for most people. Its harder to write an algorithm on the fly thinking in code, but with graphics more options might be apparent.

 

Perhaps the best solution for me is to draw something out on paper as a signal flow, then write the code behind it. Jumping straight into code isn't really the best thing when trying to go down a new path, only a familiar one.

[packrat]

I think everyone should be forced to draw a few flowcharts as part of learning to work with computers. I also believe that the really competent people internalise the process when they're thinking about what to do. This has been my experience, anyway.

 

Disclaimer: I now work for a place with ludicrously high standards which don't reflect external realities in any shape or form

 

Pictures are useful when dealing with reality (ie a physics problem), where simplifying abstractions are harder to come by.

 

B>

[urbanscallywag]

But this is [supposed to be] art, not a job. Hence the desire to distance one's self from code.

[packrat]

If you're dabbling as deep as Max, then you're basically there anyway. What irritates me is being forced to do things the long way just to maintain some sort of graphical metaphor.

 

Much as the 'I know very well how to use this CAD system, why are you making me draw lines using a crayon and a balloon animal balloon as a ruler'

 

B>

[girevik]

And again, while you can encapsulate things, if you need a non-trivial interaction between two encapsulated things you're in a world of pain.

 

 

This problem is called "tight coupling" in Object Oriented Programming/Design. The solution is to make sure your objects are decoupled/loosely coupled as much as possible.

 

The book "Design Patterns" is a useful resource for avoiding this type of situation. Yes, sometimes discovering your patch has this problem does mean you may have to re-factor parts of your patch (or program in OOP).

 

The critics of Max/MSP do have a point though in that for some applications, straight code is better than graphical programming. Hence the success of Java over tools like Rational Rose.

[XorAxAx]

The book "Design Patterns" is a useful resource for avoiding this type of situation. Yes, sometimes discovering your patch has this problem does mean you may have to re-factor parts of your patch (or program in OOP).

 

One can apply GoF and other OO patterns in Max/MSP?

[packrat]

Not in any useful way. I have a copy of Design Patterns behind me, and it really isn't especially useful in terms of dealing with Max. Max's encapsulation and data passing stuff is decidedly primitive forcing you to go the long way around.

 

Finally, and I've already pointed this out multiple times, refactoring in any graphical language is basically tossing it away and starting again because so much is uselessly bound up in layout.

 

If you had done any Max work where you needed to keep tight synchronisation between various realtime recording and data-streaming parts while at the same time triggering slow diskio, you'd have noticed where it falls down.

 

B>