Math Patch Discovery

cybero's picture

I don't know if anyone else has twigged to this, but just be chance I joined an Interpolation noodle to the what I at first thought was entirely the wrong connection point, only to find that it worked as a switch to the type of operator, positive or negative, that the patch would work with.

See attached picture.

PreviewAttachmentSize
Math Patch Discovery.png
Math Patch Discovery.png73.36 KB

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

cybero's picture
Re: Math Patch Discovery

PreviewAttachmentSize
Math Patch Discovery.png
Math Patch Discovery.png73.36 KB

vade's picture
Re: Math Patch Discovery

Wow. That... is unexpected. Nice find.

gtoledo3's picture
Re: Math Patch Discovery

It's always worked that way! ;-) It's less obvious because of the shit SL patch layout.

vade's picture
Re: Math Patch Discovery

That is a shit UI design choice then, let me tell you. I forgot about 10.5 doing that, and fuck if I ever would have found that on my own, or intuited it...

usefuldesign.au's picture
Re: Math Patch Discovery

I guess I've got a least a little thing to be greqtful for being on 10.5.8 (a Superior GUI skin)!

Any patches with menu option inputs can do this — as gt implied.

A neat way to get the menu text out of the NIB is to make an input splitter for the input of interest, show patch settings (Sft-Cmd-I gives an Inspector panel locked to the selected patch), create a multiplexer patch with same number of settings and set to "String" value type.

Finally cut and paste the words from the settings inspector to the Input Parameters on the "String Multiplexer" Patch.

See attached comp for example.



Side Note
Hey Smokris I just dicovered the bold typeface is very strong in the Kineme pages css/style. More like a Heading typeface than a inline bold typeface. Actually good when size is small but pretty heavy for normal type ;)

PreviewAttachmentSize
Index Splitter on Menu choice.qtz19.6 KB

cybero's picture
Re: Math Patch Discovery

Quote:

It's always worked that way! ;-)

LOL

Do you know what, almost as soon as I posted that picture I thought somebody's going to say something like that.

Still a semi useful serendipitous discovery.

gtoledo3's picture
Re: Math Patch Discovery

Well, in 10.5 and before it actually had input ports. I think someone (tobyspark?) actually used to complain about the size of the old math patch, which likely led to this extremely poor choice.

cybero's picture
Re: Math Patch Discovery

You're right, it was an explicit input on the old QC patch. No chance discovery of that facility required on that older OS X then :-)

usefuldesign.au's picture
Re: Math Patch Discovery

Oh ok then, I missed the point.

98% of the time I use the Math Expression patch. It's smaller and you can see the expression in the Editor window. Has anybody profiled them to see if there is a execution difference in speed when using heaps of them, (one being parsed, the other not)?

cwright's picture
Re: Math Patch Discovery

It depends on the expression -- typically Math Expression is faster (I think I profiled with Performance Inspector back in the day), but there could be cases to the contrary.

While Mathematical Expression is parsed, it's actually baked down internally to a simplified form that makes its evaluation a bit faster than if it processed the raw string every time.

cwright's picture
Re: Math Patch Discovery

gtoledo3 wrote:
I think someone (tobyspark?) actually used to complain about the size of the old math patch, which likely led to this extremely poor choice.

Walls have ears, but it wasn't just external complaints that drove the UI redesign.

usefuldesign.au's picture
Re: Math Patch Discovery

cwright wrote:
While Mathematical Expression is parsed, it's actually baked down internally to a simplified form that makes its evaluation a bit faster than if it processed the raw string every time.

I was wondering if that was possibly the case, good news!

usefuldesign.au's picture
Re: Math Patch Discovery

cwright wrote:
Walls have ears, but it wasn't just external complaints that drove the UI redesign.
Internal complaints/Marketing Department wanting a 'fresh look'/Entropy/SL compliance/Other?

franz's picture
Re: Math Patch Discovery

gtoledo3's picture
Re: Math Patch Discovery

Another thing I'm finding that's really irritating is that it can't be renamed in the editor, like other patches.

dust's picture
Re: Math Patch Discovery

i like the new UI. particularly how the math patch is smaller. it took a bit getting used to but i don't think the redesign hinders any productivity or intuitiveness of the redesigned patches. i also find it more aesthetically appealing, but apparently it seems i'm alone on this one.

i can see the point of the operand index being in the middle of the patch and how that could be confusing but don't understand why there is so much surprise to people finding out it works just the same as it did in qc 3.

gtoledo3's picture
Re: Math Patch Discovery

Ok:

There is only ONE patch in the whole system that doesn't show input ports for inputs, and doesn't allow one to add a custom name. If it didn't hinder intuitiveness, we wouldn't actually have a thread devoted to it or be having this conversation, because Cybero ( and Vade, and whoever else), would have already noted it.

The patch was largish, but I see no point in not visually representing inputs, or not allowing one to write in a name. At times I like the small footprint, and I sussed out the input port thing really quick (as soon as I saw the object in SL pre-release, I flipped to Leopard, made a composition, opened it back up, and saw the noodle in the frikkin' middle of the patch... and was "sorta" relieved.) I don't think it does experienced users or newbies any favors though. I think that the language of QC is that an input has an input port, and this is an unfavorable corruption of that paradigm.

The new UI is slicker in some ways. Poor performance, lack of consistency of implementation of many features, and many glitches aren't a big smile maker for me though. I think the cumulative effect of Kinemecore in Leopard (especially with linear noodles), is a way bigger win Editor feature-wise than the Editor improvements that happened in SL.

cwright's picture
Re: Math Patch Discovery

dust wrote:
i also find it more aesthetically appealing, but apparently it seems i'm alone on this one.

I think the mistake there is that at the end of the day it's a tool -- how well it allows you to do your job is more important than how pretty it looks. I have screwdrivers that I got from my dad that are probably 75 years old (from his father, etc), but they work like a champ (wood-carved handles and all!). I don't care so much that they don't have grippy rubber handles or pretty see-thru plastic grips.

I don't at all care about the facelift -- I am/was concerned by how it interfered with using the tool though (if newer screwdrivers were half as fast as old ones, you'd stick to old, regardless of aesthetics, unless you were only casually interested in actually using the screwdriver to drive screws).

dust's picture
Re: Math Patch Discovery

yes a tool is only as good as the function it performs. its like i would not wear a pair of shoes that are uncomfortable just because they look cooler. so i'm thinking maybe there was a facelift for more reasons than aesthetic appeal. like george mentioned a smaller foot print perhaps to save more space ? i mean there has to be a good reason. the math patch is an indispensable tool that has faster equivalents but all the same i still use it. so i guess the math patch is a screw driver with a new fancy grip, js is a screw driver with inter changeable bits and the math expression is a power screw driver.

usefuldesign.au's picture
Re: Math Patch Discovery

I think it's a mistake to think that appearance has no bearing on how effective software tools are to use. You might not actually be saying that appearances are irrelevant in software, cwright, so I don't want to put words in your mouth, but GUI is definitely about appearances when they affect user interaction which is the other side of the GUI equation.

ApplePro apps are all grey toned so as not to distract from the media content and influence ones colour perception of the content for example — not just to look 'serious' when compared to the 'fun and easy' iLife suite.

Adobe Acrobat Pro has a dog of an interface and even one official Adobe CS evangelist has said exactly that to me. It doesn't mean you can't use it, it's just a pain to find commands you haven't used in ages because there's poor thinking behind the division of tasks.

I remember not liking MacOS8 at first (just on appearance level) and OSX at first but got used to them, then preferred them.

Some pontificators in marketing industry make the argument that at Apple is all about appearances, as if good industrial design is only about making objects that create desire/envy on a visual level and that's the key to Apples success, as if they are just building stock PC's/mp3 players in pretty boxes. So pretty, we all feel compelled to upgrade to the latest model every cycle.*

Anybody reading this knows what a crock that view is and it's the attention to detail on all levels is the hallmark of a successful Apple product be it software or hardware — usually it's a combination of the two. I could go on & on about this because it's a pet topic of mine... In short appearances do count but only when they are the embodiment of a deeper design philosophy, ie when it's useful on some level. (Turn screws in a better way).

* I'm reading The Language of Design by Deyan Sudjic atm and he says exactly that about Apple hardware.