Magic Music Visuals

Well, not really. Just bringing together a few simple elements. Could be much more developed but just having a bit of fun at this stage.
Even with fairly simple elements the final project is quite complicated - admittedly, not using sub-scenes as much as I could. Found I was using scale/transform/rotate in that order for most elements. It would save quite a lot of project real estate if those operations could be combined into a single node and a simple colour control integrated into all nodes.

Also, type-on effect for the text would have improved the code effect. Randomised letter/digit spinning would have also been useful. Strange how I'm still compelled to skeuomorph green CRT for a modern starfleet Constitution class ship.

Music: https://www.youtube.com/watch?v=9138Ppy-Htw
LCARS image template: https://throughthepanes.wordpress.com/2 ... ce-update/
Ship models: http://www.trekmeshes.ch/
Code: OpenGL from Shadertoy (but which one?)

To Boldly Go Again...

Very cool! Love it.

Found I was using scale/transform/rotate in that order for most elements. It would save quite a lot of project real estate if those operations could be combined into a single node

The reason I haven't done this is the concept of "order of operations". Everything would be forced into one specific and perhaps undesirable order if all operations were combined into one module. For example, scale->translate is different than translate->scale, and rotate->translate is different than translate->rotate, etc., etc. I suppose the most common sequence would be scale->rotate->translate, but that's just a guess.

It's the same concept as 2 + 3 * 5 = 17, but (2 + 3) * 5 = 25. Not equal, in other words. The only difference is the order of operations.

Also, type-on effect for the text would have improved the code effect. Randomised letter/digit spinning would have also been useful. Strange how I'm still compelled to skeuomorph green CRT for a modern starfleet Constitution class ship.

Yes those things would be nice, though admittedly not at the top of the priority list right now

Absolutely - on the order of operations. I've taken advantage, and been tripped up, by transform ordering and, now you mention it, I can see the rationale for maintaining separated operations.

But, for the sake of real-estate, perhaps then consider the suggestion to more neatly stack modules, having connectors somehow connect vertically. Also separately, allow annotation to persist even when the module is minimised. Finally, what about the idea of duplicating the currently selected module in a side panel where all parameters are fully expanded. This would allow one to peek inside a minimised module with minimised parameters quickly.

Sadler wrote:... allow annotation to persist even when the module is minimised...

I've asked for this before - it would be extremely helpful when space is limited.

Sadler wrote:...duplicating the currently selected module in a side panel ... allow one to peek inside a minimised module with minimised parameters quickly

or perhaps a long press on the module could make it expand. Then no need to look aside.

or perhaps a long press on the module could make it expand. Then no need to look aside.

Perhaps...but I can see two disadvantages. The point of looking to the side is so not to disrupt the flow of a minimised layout. A long press is time consuming and not much different from expanding a module (assuming all the params are already rolled down and that editing is available).

Expanding a module to the side would be quick, persistent, focused and non-disruptive allowing a performer to jam with a module in a live situation. I know MV isn't trying to emulate every software out there but I believe this is how TouchDesigner deals with module parameters.

Everything would be forced into one specific and perhaps undesirable order if all operations were combined into one module.

This Pixar video explains order of transformations visually (from about 1 minute in). From Khan Academy's Pixar in a Box lesson.

But, for the sake of real-estate, perhaps then consider the suggestion to more neatly stack modules, having connectors somehow connect vertically

This wouldn't really save real estate though, it would just change how the connectors look, right?

Also separately, allow annotation to persist even when the module is minimised.

Yes, on my list already.

Expanding a module to the side would be quick, persistent, focused and non-disruptive allowing a performer to jam with a module in a live situation.

I understand that it would be non-disruptive to a minimized layout, but would it really save time? Pressing the "+" button to expand the module is pretty quick, definitely persistent, and unarguably focused

The real advantage would be if I ever implement zooming out, so that you could edit modules without zooming back in. That's probably the point at which I'd consider something like what you're proposing.

RE: vertical connectors: Yes, it would just change how they look. I would add to that, that when connectors get very short the arrow could be removed altogether. Another idea: how about snapping modules together, a la Scratch. Then we could have combined transform nodes (or any nodes) while still having control over order.

By "saving time" I was referring to the long press mentioned by Terry. You're right, the plus button is quick (but also a bit disruptive to beautiful node layouts).

I agree that it would make even more sense to have active module parameters replicated when zooming comes to MV. But it would also help with those FFGLs and IFSs that have a ton of parameters.

Ok, makes sense .

I like that Scratch concept. Very interesting.

Added another video in first post, just for fun.

Very nice!

LOL Hilariously awesome.

haha love it! seriously fun video

Love it

A great start to my day - can't stop smiling. Thanks!