Forum rss-feed

Forum

Tau: Scale key problems and other things (2.0.70)

Most Recent

written by: jsn

JSON is a nicer format as it has less noise and is a lot simpler to parse (and generate). The trick is to ensure that there is info in the JSON which tells you which "format" the file is in (i.e. a version number). That way you have the pleasant simplicity of JSON with at least some nod towards semantics.

I am tapping away on an idea for a procedural set-up approach (as I said above) - which I am using a JSON-style storage format (I am in fact doing a shared server using MongoDB - the idea being to be able to share them from a single source). This of course means changing procedural data into Belcanto statements which is causing me time at the moment as I never can keep the Belcanto straight in my head for some reason :-( Apart from my stupidity this seems to be working reasonably.

Of cpourse the killer version of this would be somehting that could reverse any workbench/browser/commander/manual changes back to a scriptable form. Is there scope or a facility for the interpreter to maybe spit this out when it is running the Belcanto?

written by: jsn

Sat, 17 Nov 2012 11:30:48 +0000 GMT

There's been a problem with the scale keys since 2.0.50ish which has never been resolved: If you set the scale choice using the Tau keyboard and the EigenBrowser the scale keys seem to no longer work (even if you save and reload the set-up).

This is very frustrating - I end up having to use EigenTab all the time to quickly swap scales.

In fact, I would say I can't really use these versions and I keep going back to 2.0.48-experimental as the last really working version. Particularly irksome as I now pay for it !!! (The Pro version)

This is almost as frustrating as none of my set-ups EVER upgrade to the next version consistently, so I end up re-configuring the Tau from a Factory default each time. Consequently, I do not update my EigenD regularly.

It would be useful to me if there was a script issued for the complete Tau set-up from nothing. This gives me two advantages:
- I can diff the previous script and the current script to see what is different/added/changed
- I could easily modify it how I need in a script rather than having to either use the Workbench (slow, visual paradigm) or manual Tau/EigenBrowser/EigenCommander way

Actually, what would be more handy would be a way of being able to dump a configuration to a pure Belcanto script that can be replayed to recreate the set-up. This way I could take the Factory (or other) set-up and modify it in a replayable form for my needs (and this would negate EigenLabs having to create a script each release).


written by: GoneCaving

Sat, 17 Nov 2012 12:06:10 +0000 GMT

I can see how that would be really frustrating. Might be worth sending the setups to Eigenlabs to see if tere's a bust in the way the setups are being migrated?

As far as I'm aware,and from what I know of how the setups have been built, no such script exists. The setups are built using Workbench these days (Geert, please correct me if I'm wrong). There was talk of changing the setup persistence from binary to something text based (XML?). Is that on the roadmap for 2.1?


written by: jsn

Sat, 17 Nov 2012 12:08:35 +0000 GMT

Please, by whatever god you believe in, NOT XML ! Belcanto is better for this domain


written by: jsn

Sat, 17 Nov 2012 12:54:38 +0000 GMT

And the "rhythm tap" keys don't work either


written by: geert

Sat, 17 Nov 2012 15:37:03 +0000 GMT

Hi John,

I see what happened in the Tau setup, I overlooked some of the scale talkers for the upgrade script when we renamed the variable that holds the scale definition. I'll work on a fix next week. Sorry that this has been around since 2.0.50, but nobody has reported it before.

I'll keep you posted next week.

Take care,

Geert


written by: jsn

Sat, 17 Nov 2012 16:07:04 +0000 GMT

Thanks, Geert.

Pretty sure I posted a bug via the menu item in 2.0.50 for this....and the rhythm tapper, too. Oh, well - technology, eh?

How about the "dump to belcanto" idea ? How hardwood it be? Something I could add via dev version? Or is there a way of converting set-up to belcanto?


written by: geert

Sat, 17 Nov 2012 16:17:36 +0000 GMT

Hi John,

Dump to Belcanto is very hard as setups really are a state tree, apart from the talker phrases, nothing is really linked to the Belcanto that could generate that tree. So dumping to Belcanto would be a massive undertaking and very error prone.

I can't reproduce the rhythm tap keys problem you're mentioning, they work in Tau Factory setup of EigenD 2.0.70. Can you please check if they do for you in that setup?

This script should fix the scale talkers in Tau setups that have been upgraded through the factory setup fixes or the factory setup of 2.0.70 itself. I hope this helps you with your problem, I'll do the rest of the work related to this next week.

Take care,

Geert


written by: jsn

Sat, 17 Nov 2012 17:05:45 +0000 GMT

Ok, but just like writing a decompiler you could generate a script (not necessarily the script) from the tree, unless there is missing information?


written by: jsn

Sat, 17 Nov 2012 17:06:51 +0000 GMT

Thanks, I'll try that. And check the tapper, again, in 2.0.70 just in case I screwed something.

Even though the data structure is a tree it must be possible to walk the tree and generate the belcanto. It was created that way, it must be reversible - OK it's not trivial as you'll need to analyse it and keep state but cable. Is this tree fully posed in the code? I might have a go at it...


written by: geert

Sat, 17 Nov 2012 17:39:21 +0000 GMT


written by: geert

Sat, 17 Nov 2012 17:15:40 +0000 GMT

John, reversing the state of the tree to find the Belcanto is similar to saying that you have any tree in C++ and that you can find which classes and methods were used to generate it. Even though the outcome is a particular state, there's nothing stored with that state to tell you how it got there, nor what the side effects are when doing so.


written by: jsn

Sat, 17 Nov 2012 17:25:54 +0000 GMT

But just like writing decompiler , surely you can generate a script from the existing tree - it won't be the original script/scripts but it would be sufficient....unless tree is missing info ?


written by: geert

Sat, 17 Nov 2012 17:38:58 +0000 GMT

The state tree is just a collection of values and entries, no symbol information that indicates how they got there, so there's no way to go back. Any code anywhere in the agent might have manipulated the tree, nothing links the state data to the code and nothing links the code to Belcanto statements.


written by: jsn

Sat, 17 Nov 2012 18:38:39 +0000 GMT

That script fixes the scale problem - thnx.

The rhythm tapper works too - I think there might have been some kind of consequnece with the scales not working that caused the rhythm tapper to not work. It is fine with that script in place now.

I'm sure you're right - you know the code better than I - but it seems sad you can't do this. I will have to resort to my plan C of writing something to help me set-up my Tau without using Workbench and/or EigenBrowser which is a bit more procedural...


written by: john

Mon, 19 Nov 2012 14:23:46 +0000 GMT

Hi John

I can understand your aversion to XML, I have similar feelings. We would like to make the setup files have a plain text format at some point though, and Geert is right, Belcanto is probably not a good choice for this as the information that would make the file structure readable is just not there in the setups and it would be a lot of work to make a suitable encoder to put this back. It's probably not impossible, just a lot of work, enough work that we'd likely never get to doing it.

Do you dislike JSON as well as XML? It has occurred to us that this might be a nicer format than XML, though we haven't spent a lot of time thinking about it as yet.

John


written by: jsn

Mon, 19 Nov 2012 14:52:36 +0000 GMT

JSON is a nicer format as it has less noise and is a lot simpler to parse (and generate). The trick is to ensure that there is info in the JSON which tells you which "format" the file is in (i.e. a version number). That way you have the pleasant simplicity of JSON with at least some nod towards semantics.

I am tapping away on an idea for a procedural set-up approach (as I said above) - which I am using a JSON-style storage format (I am in fact doing a shared server using MongoDB - the idea being to be able to share them from a single source). This of course means changing procedural data into Belcanto statements which is causing me time at the moment as I never can keep the Belcanto straight in my head for some reason :-( Apart from my stupidity this seems to be working reasonably.

Of cpourse the killer version of this would be somehting that could reverse any workbench/browser/commander/manual changes back to a scriptable form. Is there scope or a facility for the interpreter to maybe spit this out when it is running the Belcanto?



Please log in to join the discussions