!Epoch, for the next 4 years

[colin@loomer]

No, it's just resting before a beautiful butterfly emerges.

[bungle]

We can start a new one then, surely ?

[jowen]

colin@loomer wrote:
No, it's just resting before a beautiful butterfly emerges.

This is not what we want to see, a butterfly?
Do you know that a butterfly only lives from several weeks to one year in max?
And its sleeping most of its time?

Hey, we are waiting nearly five years now, we want more than a butterfly!

Are there some pictures of the chrysalis possible?

[colin@loomer]

Butterfly was a bad analogy; I meant Galapagos turtle.

Polishing, refining, bug-fixing has been the development focus of late. This likely doesn't mean much to anyone other than developers, but I replaced the object reference-counting system with a mark-and-sweep garbage collector after realising how much time was spent incrementing references count; a much welcome boost in performance.

I've been trying to replace monolithic modules (built-in component which can't be edited or changed) with macros (which are composed of modules and macros) where possible. It's a balance between performance and flexibility, but I am leaning towards a small module library bolstered with a larger library. The current module count is about 250, which is more or less where it should stay for the foreseeable future.

I also added a type-checking system to macros. To give an example, I have a generative patch which uses a macro that selects the lowest pitch from an array of pitches, which will then be routed to a bass tone synth. Now, if you send anything other than an array of integers to the macro, it will catch the error, but the error will occur somewhere in the macro innards and not immediately be obvious to a user just why this isn't valid.

You can build your own type checking using the built-in modules - use a "get type" module to to query the received object's type, and then "compare" it to the allowed types: a pretty standard way of doing type-checking when you have dynamic typing. The problem here was that the type checking module count often exceeded the module count of the macro's main function, and made the macro flow so much harder to understand.

So I've implemented a new system where macro inlets can (optionally) have an acceptable type property. This gives us the benefit of early error reporting, and yet doesn't clutter the main module flow. The macro I mentioned above, for example, has a Type Check property value of: "nonempty array[number]". On receiving the wrong type of object, the macro will raise an error and report: "(28): unexpected type: expected nonempty array[integer or float]" (where 28 is the module id). You can build quite flexible acceptable types using a simple grammar: things like "nonempty array[boolean or string] or map or tuple(string, boolean or float)" are fine, so you can nail down the types very specifically.

I've also been working on documentation, coming up with guidelines for building your own well-behaved macros, etc. There are some subtleties with initialisation order - ensuring that events fire in the correct order when the patch is first opened - but it's not an issue provided you follow the guidelines.

[jowen]

colin@loomer wrote:
Butterfly was a bad analogy; I meant Galapagos turtle.

Ok, ok I see it is very hard to see the difference between this animals?

Anyway, are there some pictures of the eggs or the little babys

[colin@loomer]

I'm mid-way through changing fonts and experimenting with a few different styles and schemes, so things are a little Picasso at the moment. I've scheduled time early next week to finalise the outstanding GUI niggles, so I'll aim to get some new screenshots up then.

[ThomasHelzle]

The butterfly analogy at least made it clear that it won't hatch this winter...

BTW. to anybody interested in these kind of things, I recently participated in a code-jam here in Berlin and we tried out magenta/tensorflow as a generative midi tool. It's quite easy to install on OSX and Linux and I found it quite fascinating (here is the code and basic installation/run info: https://github.com/atomicguy/codejam ).
Could become a nice module in !Epoch 2.0

Cheers,

Tom

[colin@loomer]

Nice one, Tom: I'll have a look at this this weekend!

[HunterKiller]

Butterfly was a bad analogy; I meant Galapagos turtle.

Polishing, refining, bug-fixing has been the development focus of late. This likely doesn't mean much to anyone other than developers, but I replaced the object reference-counting system with a mark-and-sweep garbage collector after realising how much time was spent incrementing references count; a much welcome boost in performance.

I've been trying to replace monolithic modules (built-in component which can't be edited or changed) with macros (which are composed of modules and macros) where possible. It's a balance between performance and flexibility, but I am leaning towards a small module library bolstered with a larger library. The current module count is about 250, which is more or less where it should stay for the foreseeable future.

I also added a type-checking system to macros. To give an example, I have a generative patch which uses a macro that selects the lowest pitch from an array of pitches, which will then be routed to a bass tone synth. Now, if you send anything other than an array of integers to the macro, it will catch the error, but the error will occur somewhere in the macro innards and not immediately be obvious to a user just why this isn't valid.

You can build your own type checking using the built-in modules - use a "get type" module to to query the received object's type, and then "compare" it to the allowed types: a pretty standard way of doing type-checking when you have dynamic typing. The problem here was that the type checking module count often exceeded the module count of the macro's main function, and made the macro flow so much harder to understand.

So I've implemented a new system where macro inlets can (optionally) have an acceptable type property. This gives us the benefit of early error reporting, and yet doesn't clutter the main module flow. The macro I mentioned above, for example, has a Type Check property value of: "nonempty array[number]". On receiving the wrong type of object, the macro will raise an error and report: "(28): unexpected type: expected nonempty array[integer or float]" (where 28 is the module id). You can build quite flexible acceptable types using a simple grammar: things like "nonempty array[boolean or string] or map or tuple(string, boolean or float)" are fine, so you can nail down the types very specifically.

I've also been working on documentation, coming up with guidelines for building your own well-behaved macros, etc. There are some subtleties with initialisation order - ensuring that events fire in the correct order when the patch is first opened - but it's not an issue provided you follow the guidelines.

Skynet begins to learn at a geometric rate. It becomes self-aware at 2:14 a.m. GMT, January 20th.

[mooneh]

Hoping for a Christmas present..

[VariKusBrainZ]

Hoping for a Christmas present..

Not.A.Chance.

[very angry mobster]

Hoping for a Christmas present..

Aren't we all.

[mooneh]

[jowen]

VariKusBrainZ wrote:

mooneh wrote:
Hoping for a Christmas present..

Not.A.Chance.


We have a chance , we just need only to specify the year?

The song 2525 came in mind this second, could this be a sign?

[VariKusBrainZ]

But in seriousness, like most others in this thread my money has been waiting to throw itself at Epoch since forever