!Epoch, for the next 4 years

[grinzler]

I don't get why a developer would try and be cute and crack jokes after this long drawn out customer/community interaction. The dev keeps a blog but no weekly or monthly updates? Is there a reason why optimizations would get in the way of a beta test? Unlike some filter emulation, you promised a program that could totally change and improve a workflow. It's like being in a long distance relationship where the person drags you along saying "i'll visit for christmas" then "i'll visit early next year" then "i'll visit at the end of the year" then "i'll visit when I loose ten pounds" and then "lol I lost ten pounds now my clothes don't fit, wait till I go shopping".

[prupert]

The buy out of Camel Audio was such a shame - Alchemy 2 looks an awesome tool - but being locked down as is Apples way within their ecosystem is so sad. Give it five years and it'll be a footnote in the Producers repertoire.

Please don't go that way - or at least release Epoch first and then sell your soul to that corporate devil.

[colin@loomer]

It's a massive development project, and I made the decision to get it right before I get it out. Unfortunately, that does sometimes mean that I've got to put my nose to the grindstone and get coding, which can come at the expense of keeping you all posted.

My main concern with not going beta yet is mainly due to backwards compatibility. Whilst I can closely control the user base and can make clear that backwards compatibility may break - and has done, many a time - that's not something I can really say once it's in the wild. I think if each new version rendered previous patches obsolete, user's would get pretty miffed. Of course, I could maintain backwards compatibility, but it's just more work to keep a legacy, and likely wrongly designed, element in place.

But you're absolutely right, I could do with being more open about what's going on. At the moment, I'm collating all the constant types into a single constant module. Previously we had a module for constant integers, one for constant doubles, one for strings, etc. But this was wasteful - they all do the same thing, essentially, and made creating more complex values from base values a little awkward. There are various constructor modules that help with this: there is, for example, a list range module, which creates a range of values. Still, it didn't quite do it well, and very often there was more plumbing in place to get values created than there were to use them.

So now we have a single constant module, which produces any values whatsoever. It infers the types based on what is typed in:

• 23 is an integer
• 23.5 is a double
• true or false are boolean
• "strings can be quoted" (or in a list [seperated with white space])
• Lists are enclosed in square brackets [ 1, 2, 3, 4 ]. We can also have lists of lists, and so one [ [1, 2], [3, 4], "hello" ]
• There are a couple of special types too: Signal is a generic "do something" event, carrying no value. Null is an event without any value.
• There are also midi types, but they are created in a different way using specific modules. Each midi type has both an unpack and pack which, formerly, unpacks a midi event of the specified type and produce values based on the midi data, and latterly, converts these values back into a midi event.

So I'm currently finishing off the parser for actually creating these. The difficult part is done - these values are edited by the user on the UI thread, so I create an AST and pass it off via a lock-free system to the audio thread when they are changed, but I'm just wrestling with some of the finer intricacies of flex and bison to get the parser running.

Point taken though: I will endeavour to update the forum with progress reports as often as is possible.

[bungle]

Colin, worry less about the forum than you should about some mug with 13 posts coming on here to give you grief, it is obviously a big undertaking, nobody here needs updating, non of us are funders/backers/shareholders, do your thing and when it is ready we will do ours

[Valery_Kondakoff]

Based on Colin info !Epoch which was announced years ago as modular MIDI environment (think Numerology) is developed into something like the "Max" part of Max/MSP. Is this true? So, what are the differences between Max and !Epoch?

[whyterabbyt]

Based on Colin info !Epoch which was announced years ago as modular MIDI environment (think Numerology) is developed into something like the "Max" part of Max/MSP. Is this true? So, what are the differences between Max and !Epoch?

well for one thing, MAX wont run as a plugin. And !Epoch probably cant be used to build a web-browsing video-projector based art installation that interfaces with Arduino-controlled bulldozers.

[colin@loomer]

Yes, that's a fair summary of its path. It started off as something like a next-gen Thesys - several step sequencers working in tandem - but evolved into something more akin to Max. It's a proper programming environment now, albeit one in which writing anything that isn't based on MIDI processing is probably more hassle than it's worth! On saying that, I do have a pretty snazzy Pong implementation, and MIDI controllers make excellent rotary paddles for that authentic feel.

Some of the differences between this and Max, other than the fact they are different languages as such:

• Everything occurs at a guaranteed time. Events are all clocked and are absolutely guaranteed to happen at that clock time.
• Setting module values and activating the module are totally separate. Rather than having hot inlets that also take values, modules that have more than one inlet also have an activation inlet. I could probably write a book about the trials and tribulations of getting the event system finalised, but there are many advantages to this method. This means that, for example, a simple binary subtract module can be activated by events going into either the minued or subtrahend. With Max et al, having events activated by their cold inlets requires plumbing.
  
  This also solves the conceptual concern about which parameter should be considered hot events. With a list append module, taking both a list and a value to append to it, which would be considered the event that causes the module to activate? Neither seems conceptually more right, and I think removing that option is better.
• Each inlet and outlet does one thing and one thing only. The downside is that some modules have lots of inlets, but by default they are mostly hidden and revealing an inlet is as simple as clicking a button on the module's properties.
• Native midi data types.
• All mathematical modules can process vector and scalar quantities a la vvvv or R. If you have a list of say MIDI pitches, [60, 62, 64, 65], you can add that to a scalar 12 to get [72, 74, 76, 77], or even to another vector, such as [12, -12] to get [72, 50, 76, 53]. In the second case, values are 'recycled' as they say in R parlance. Again, very handy when you are processing MIDI data.
• Lots of sequencing options, such as a full DAW style arranger.
• Lots of real-time playing options, similar to Ableton Live's scenes.
• Proper DAW style mixer for hosting plug-ins. This also includes a very flexible routing system, as well as the usual stuff you'd expect, pre/post fader sends, etc.
• It runs as a plug-in as well as standalone.

Lots of other differences too, but that gives you at least a flavour.

[Valery_Kondakoff]

Colin, thank you for the useful info!

[bungle]

HUI/HID module yet ? (later version if at all i would guess)
Really want to be able to map things like Maschine direct to this, could be killer to get those screens and such

[UncleAge]

Thanks for the detailed info. I gots no problem with the wait so please carry on...

[deastman]

All the sharing of details is completely unnecessary, but greatly appreciated. Just continue doing what you're doing, and it will get there eventually.

By the way, my wife is a (very) casual acquaintance of Mr. Cook. I'll have her put in a word for you about the statue.

[colin@loomer]

HUI/HID module yet ? (later version if at all i would guess)
Really want to be able to map things like Maschine direct to this, could be killer to get those screens and such

On the roadmap, but I haven't done much in the way of research into it one way or another.

As an update, it turns out that writing a thread-safe parser using C++ in flex and bison is tricky. In fact, the - admittedly old - book I have on Bison says it's impossible. I found some lovely replacements that do the same job: re2c is a better flex, an lemon is a better bison. Both produce thread-safe code, as I can attest after staying up late finishing the parser whilst watching the pound plummet.

[prupert]

Depressing isn't it? Such an important / complex decision should never have been put to a public vote. Ahh well, we might all be broke the next few years, but at least we have music.

[grinzler]

Sorry about the rude comment. I was left alone at malls a few times with "i'll be right back". Trust is thoroughly broken. I also feel spoiled by the professionalism of devs like Sean Costello who seems to empathize with and respec user expectations. In my opinion beta testing shouldn't require backwards compatability or even a feature for saving patches. Having a handful of people testing indivudal modules and general ergonomics is useful to do before the program is "crystalized" see the latest silicon valley episode for example.

[bungle]

So you make a rude comment, apologise and then condescend, just well done on that right there !!