Forum

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).

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

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

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

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...

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.

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.

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