!Epoch, for the next 4 years

[very angry mobster]

@colin: I've played with Reaktor and Max a little. There has been at least one time in each application where I was building a patch which caused Reaktor or Max to crash. Not annoying so much in itself, but subsequent attempts to open the patch to continue working would trigger another crash. It's really hard to recover from that kind of error. The patch is pretty much lost unless you have a earlier version backed up somewhere.

Will !Epoch be able to recover from the same type of error?

[colin@loomer]

The entire patch is stored as XML, so if, for some unlikely reason it did become corrupted, one could in theory examine the XML structure and either fix the issue, or at the very least remove the offending element and load the majority of the patch.

Also, I've ensured that malformed XML patches do not, under any circumstances, crash. I have a validation process that ensures that everything is internally consistent when a new preset is loaded. Admittedly, the error messages when an invalid state occur aren't yet very specific, but, if needed, I could add directed messages to let one know exactly what is wrong with the preset.

[very angry mobster]

Text is great! We'll be able to put our patches in version control!

[colin@loomer]

As I was sprucing up the audio pool interface, adding threaded thumbnail loading and caching to ensure the ui is responsive even when dealing with large recordings, I realised one exception to what I stated above about self-contained patches: audio files are not stored in the XML file. It's just not practical to embed potentially gigabyte-sized audio recordings in the patch, so audio files are saved separately in an audio pool folder.

MIDI recordings on the other hand, tending to be very small, are stored (albeit as opaque binary) within the XML.

[jensa]

...audio files are not stored in the XML file. It's just not practical to embed potentially gigabyte-sized audio recordings in the patch, so audio files are saved separately in an audio pool folder.

MIDI recordings on the other hand, tending to be very small, are stored (albeit as opaque binary) within the XML.

That's great. I don't want to fill up my git repo with binaries.

[sl1914]

I decided to check the status of this project today. Reading some recent messages and seeing the screenshots from August I can understand that this takes a long time to develop.

I was wondering if the first release will happen during 2016 or later?

[colin@loomer]

Aiming to release within the next couple of months. Admittedly I'm terrible at deadlines, but by sheer virtue of having little left to polish to get this ready for public consumption, I'm confident.

[woggle]

Aiming to release within the next couple of months. Admittedly I'm terrible at deadlines, but by sheer virtue of having little left to polish to get this ready for public consumption, I'm confident.

[HunterKiller]

You know, I'm not sure if it's just me noticing this, but people who are terrible at deadlines, most of them at least, are f**king awesome when it comes to quality. Our world leans towards quantity, so there is this disrespect/misunderstanding towards the pursuers of quality.

[woggle]

You know, I'm not sure if it's just me noticing this, but people who are terrible at deadlines, most of them at least, are f**king awesome when it comes to quality. Our world leans towards quantity, so there is this disrespect/misunderstanding towards the pursuers of quality.

agree - I'm really disappointed that I haven't had Epoch for years for obvious reasons, but I am not at all annoyed at Colin because of that. Looks like he is making an amazing bit of software and learning heaps as he does so. At the start he did not predict (or understand) how big a job was before him but he has stuck it out. That's a great quality in a person.

[colin@loomer]

Thanks chaps; as always, I really appreciate the goodwill and patience.

[bungle]

You know, I'm not sure if it's just me noticing this, but people who are terrible at deadlines, most of them at least, are f**king awesome when it comes to quality. Our world leans towards quantity, so there is this disrespect/misunderstanding towards the pursuers of quality.

I don't really agree with this, people who are in to quality tend to not set deadlines

[HunterKiller]

You know, I'm not sure if it's just me noticing this, but people who are terrible at deadlines, most of them at least, are f**king awesome when it comes to quality. Our world leans towards quantity, so there is this disrespect/misunderstanding towards the pursuers of quality.

I don't really agree with this, people who are in to quality tend to not set deadlines

Well that's an absolute that we can't possibly measure across the population. I myself am a person inclined towards quality, but deadlines are important, otherwise you would tinker forever and nothing would come of it. I set them and see what I can do within the time limit. Part of the exercise is also learning to become more productive but not so productive as to destroy the creative/inspirational/dreaming process (which itself can be enhanced by other things. So that one does not have to wait or is burned out.).

Flexibility with the deadline itself is a discipline.
It also depends what field you are in, and what you are doing.

[abstractcats]

I've been away from kvr, far to long! Do we have a new name, yet?
Hope every one, is well at Loomer, and the kvr family

[colin@loomer]

Thanks Scott. All is going well; I'm currently tidying up data structures. As usual with these things, one tiny change ripples through and causes many more changes than originally planned. Realising that using lists for everything made parsing user intent trickier than it need be, I added a tuple type. By separating lists from tuples, I can clearly know how a message should be interpreted. So, for example, writing to a table module, which is just a fixed size array module with a flexible bar-chart style UI, the basic component you would likely use if you were making your own step sequencer, you can send messages in many configurations depending on what you need:

• A single value, which will write the value to the first element.
• A tuple of destination and value (12, 56.6), which will write the value 56.6 to element 12.
• A list of destination and value tuples [(12, 56.6), (14, -4.6), (16, 23)].
• A single destination and list, such as (1, [23, 27, 32]), which will write value 23 to step 1, 27 to step 2, etc.

So tuples turned out to more work than I planned, and I also had to create a Lua userdata type to allow tuple processing within Lua, but it's worked out nicely. Generative patches tend to have a lot of code that writes values to various destinations, be they tables, sequencers, or whatever, and making this fundamental aspect as easy and flexible has proven to be a good thing.

I also added a list userdata to Lua, rather than mapping lists directly to Lua tables. One can still extract a list's contents to a table with the list.pack method. This seemed sensible for consistencies sake, and also to allow direct comparisons. Because Lua table comparisons are (unless metatables get involved) done by reference rather than value semantics, { 1, 2, 3 } == { 1, 2, 3 } would evaluate to false. By wrapping lists in my own userdata types, our collections evaluate comparisons as you would intuitively expect.

And sorry for the rather tech-talk heavy update; I've been stepping through Lua garbage collection code, so my mind is currently in full-on Neo mode. If anyone wants me to elaborate on what any of this means, feel free to ask!