!Epoch, for the next 4 years

[colin@loomer]

Thanks; much appreciated. And whilst I'll agree to the well thought out, I think calling my development process on this "efficient" may be stretching the definition!

[HunterKiller]

Efficient - I meant the end product. You know how software was done in the old days, when there wasn't much hardware resources and when hardware cost was high, software had to be efficient and bug-free.

The development process, like life, was a learning exercise in and of itself, it added good value to you. It's win win on all sides.

[colin@loomer]

Thanks Rich; always good to hear your take on things.

[pinki]

Six years since first discussed so I think we are here at the half way point around now...so my bet is on February 2024

We could start a sweepstake! Say £1 to enter? You have to name Month and Year and the closest wins.

I'm in. And I'm sticking with Feb 2024.

[colin@loomer]

It's a humorous idea, and I appreciate the jest, but obviously I'm gonna have to say: no, we won't be doing that!

[gentleclockdivider]

Still haven't seen any real life action of this piece of 'magical 'software .
I am starting to believe this is one of the greatest troll threads ever created .
@ colin ..please ...post some vids to proof otherwise

[colin@loomer]

Sorry; peripheral stuff like videos are a lower priority to actual bug fixing, and I've had to rework a few things pertaining to note-off handling. Essentially, it's possible to, whilst live-coding, leave hanging notes if you disconnect a cable after a note-on is sent but before the matching note-off appears.

Modules themselves have an opportunity to 'finalise' and handle this; if you delete a sequencer, for example, it will actually linger around for 1 further tick to give it an opportunity to send a note-off for any notes it is currently playing. But the same wasn't true for cable connections, and I've had a few people say that it's a pain to deal with this manually (which you can do by using a flush module; but it's a chore.) Of course, things are never quite that straightforward because you may not actually want a matching note-off: if you are branching on midi event types, you may route note-ons and note-offs via different paths, and in these cases, you won't want a matching note-off to be generated. So behind the scenes, note-on events are flagged as either matchable (in which case a note-off is automatically generated when the cable is deleted), or non-matchable. These things are never easy; but it's the little niceties like this that really make it a joy to work with, I feel.

So reworking this system is my priority. Finishing up the UI bits - and then being in a position to do videos - will come directly after, if that's OK.

[nilhartman]

Live-coding as well? Like, algo-rave live coding?
Colin, I can't wait!!!

[jensa]

Live-coding as well? Like, algo-rave live coding?
Colin, I can't wait for six more years!!!

Fixed that one for you. And obviously, we feel exactly the same...

[woggle]

Live-coding as well? Like, algo-rave live coding?
Colin, I can't wait!!!

I dont really get the live coding thing - we did quite a bit back with Impromptu (I worked with the guy who developed it and we used it in teaching) but I never found using it that attractive compared to hardware / software interfaces

[colin@loomer]

Polishing the user library, I've stumbled across what may be my favourite new macro: the MIDI queue. It's basically a wrapper around a data queue macro:



I'm hoping it's relatively clear how this works from the screenshot, at least in high-level terms. Inlets ("clear", "write", "read") are at the top; outlets ("has item" and "item") at the bottom. The red "memory" connections represent shared access to a single memory object: here, several "load" and "store" modules all write to the same shared memory area. The other cables represent top-to-bottom data flow. The "boolean" module (near the right-hand side) is a boolean coercion. This converts data to a boolean true or false depending on its truthiness. Empty arrays are falsy, so we can use this fact to detect an empty queue.

The MIDI queue wraps the data queue. The data queue is natively incompatible with MIDI, but by converting MIDI to tuple data types for storage and back again for retrieval, we can get around this.



And it's such a useful macro for building, amongst other things, humanisers. One of the main difficulties with generative or processed MIDI data is in keeping MIDI noteon and noteoff messages paired. If you lose a noteoff, you get a hung note. Because the queue maintains strict order, a noteoff will always follow its noteon. By connecting the queue "read" inlet to a timer with small random delay times, fluctuations in MIDI timings can be introduced to knock perfectly robotic messages just a little off the beat. Handy stuff!

[gentleclockdivider]

This shares a lot of resemblance with reaktor core , memory read/write modules ( latches )

[nilhartman]

Genuine question Colin : would it be possible to approximate tracker workflow ? I’m a new Renoise convertee, and would be over the moon if I could somehow mix the KB driven workflow / super fast editing with all the MIDI wizardry I’m used to as a seasoned Numerology user.
Anyway, no matter what, can’t wait!!

[colin@loomer]

I suspect I must have been inspired by Reaktor back when I designed that bit. You can get by without using references - Pure Data and MAX do (as far as I know) - but that usually means much more routing, including the dreaded feedback, to express some often simple algorithms.

[colin@loomer]

would it be possible to approximate tracker workflow ?

You'll be more than able to "approximate" it. I'll say no more.