(the product formerly known as) Epoch

[ThomasHelzle]

A thousand times faster sounds well worth your while

I personally don't want audio tracks if that's any statistical help.
What I need is a swiss-army-knife for midi, hopefully lightweight enough for use on every track in a semi-modular host like Bitwig. If it also scales well for heavier stuff that's fine, but hopefully it still stays slim enough to be usable for simple stuff.

I so look forward to encounter this epochal beast

Cheers,

Tom

[treebeard]

"Tens of thousands of clips" it's time to call Hanz zimmer!

Well done Bungle - seems you found a sense of humor along with the ability to predict what others will expect next ;D

Go Colin Go!

PS I agree with Mr Helzle - I definitely do not want any audio features contaminating this midi environment!

[bungle]

Treebeard are you purposely trying to troll ?
It has nothing to do with sense of humour or predicting anything, when you create a standalone sequencer people invariably ask for audio tracks.
This is not a prediction and oh wait....the developer himself said he had already been asked, so please stop trying to troll.

Audio contaminating a sequencing environment, how droll!!

[News From The Sky]

Put me down as another vote for no audio.

[colin@loomer]

Certainly in the near- and mid-future I can't see audio tracks being included; if I did audio, I'd want to do it right, and I'd need a lot of convincing that it'd be a worthwhile use of development time.

[bungle]

Simply put, the in thing is being a DAW whore, audio tracks will just get you more coverage, more sales, more users, but that may not be your goal

[colin@loomer]

The polishing continues. I've been reworking the look and feel of the modular area. Things were fine when we had only a few modules, but past a certain threshold, and when feedback between modules is introduced, it got difficult to understand patches at a glance.

So, the previous wire and module look has been replaced with a sleeker, and hopefully clearer, system. Modules inputs are on the left; outputs on the right. MIDI ports are coloured blue, whilst CV ports are black. Finally, the wires between modules are now curved, which makes things easy to follow, particularly when the flow starts going backwards, as can be seen in the screenshot where the MIDI output from the Velocity Sieve feds back into the MIDI delay.

[ThomasHelzle]

Interesting. Thanks for the screenshot!

Are the wire colors also related to data type? Looks pretty random in the image?
I always found that very helpful in for instance Lightwaves material editor - with one view I can see what wire is what.
I can't do that in your screenshot. The ports are much smaller and less easy to "resolve" into a data flow in my brain, the wires are much more dominant.
In Lightwave they also have a nice and simple visualisation if you for instance plug a RGB color (red) into a scalar (green), the wire shows a gradient from red to green to signify that a conversion is taking place.
So if it isn't there already I'd vote for a color-by-datatype option for the wires as well.



Curved wires are indeed very helpful - cool.

Cheers,

Tom

[ThomasHelzle]

BTW. The nodes in Lightwave also are color-coded themself in categories. Not mandatory but breaks up the same-same look a bit

Cheers,

Tom

[treebeard]

Looking really good Colin! ;D

[colin@loomer]

I'm a step ahead of you: colour coded... like this, perhaps:



With only two data types - MIDI and CV, it seems to me that it's more useful to have a variety of coloured wires; they tend to make it easier to follow a path, particularly when wires overlap. In this (contrived) example below, it's easy to at a glance see which output from the switch is connected to which input. You can also hover the mouse cursor over a particular wire to make it glow, and there are tooltips of the form "Mono Note Sequencer MIDI to MIDI Sustainer" available. Hopefully, you shouldn't spend much time scratching your head to follow the path of a flow!



Talking of automated type conversion, it was included at one point, but I took it out; it was headache inducing, and the rules governing how MIDI and CV were summed were never particularly logical. Now MIDI only connects to MIDI; CV only to CV.

The bridge between MIDI and CV now lies in specific modules: to convert a MIDI Program Change to CV, you use an "Unpack Program Change" module which produces three CV streams, trigger, program, and channel. To convert from CV to MIDI Program Change, we have the equivalent "Pack Program Change" which takes a trigger, program, and channel, and produces a MIDI stream. There are also modules to perform mathematical operations directly on MIDI: "Add Pitch", for example, will transpose all MIDI notes by the specified amount; "Scale Controller" will multiply a CC value by a certain amount, etc.

[ThomasHelzle]

Well, I find the first image much clearer but I see what you mean. To my brain, random colored wires are very confusing/attention-grabbing in themself, suggesting information that isn't there, so I would probably prefer if the two types would only have limited ranges, like red to yellow for CV and blue to green for Midi - that would still leave variation to visually unravel overlaps but without the confetti look.

The 3D-Software I work with has much more types so their colors are more important - none of them has confetti cables.
Usine also does it by data type, as does Plogue Bidule, Reaktor has pretty weak color coding on both ports and wires by datatype.

I don't know how much of a deal it is but I think it would be good to not only have confetti cables and give people an option. I'm sure I would go for non-confetti.

I'm fine with conversion nodes, many 3D apps do it that way actually. Softimage XSI/Mental Ray for instance automatically inserts a conversion node when you connect incompatible but translatable ports, in this case for instance "Scalar2color" (and again the nodes are color-coded):

Midi is a pretty weird beast in comparison though and can't be unraveled as easily as those basic types.

Cheers and thanks for the updates!

Tom

[colin@loomer]

You do have the optional for per-type colouring: I just never seem to use it. I guess I've just got used to confetti colours. But, as I said, the option is there, and for you Tom, I'll make sure it stays that way!

I did also experiment with thicker cables for MIDI, thinner for CV, but it seemed just too subtle to really be useful. Maybe I'll have a play around and see what I come up with.

[2020]

You do have the optional for per-type colouring: I just never seem to use it. I guess I've just got used to confetti colours. But, as I said, the option is there, and for you Tom, I'll make sure it stays that way!

I did also experiment with thicker cables for MIDI, thinner for CV, but it seemed just too subtle to really be useful. Maybe I'll have a play around and see what I come up with.

May i suggest dashed cables for MIDI (discrete values), continuous for CV?

Best,
2020

[ThomasHelzle]

You do have the optional for per-type colouring.

Ah, sorry, I misread your post to say that you first tried per-type but then replaced it.
I'm fine if I have the option - thanks

Yeah, wire thickness is rather subtle if you don't go overboard. I could imagine having two different color ranges as I wrote above, so you would have both, data-type grokability and per-cable differences.

Did you experiment with the node corners being slightly rounded, having the title centered and a slightly colored bar behind it? Could be a way to color-code them. I somehow find them a bit bland ATM. Doesn't kill me but could be nice to have them a bit more "tangible".
I guess I personally would also make them a bit darker.

But hey, that's nit-picking - the usual "deformation professionelle" with graphics people

Great work!

Cheers,

Tom