Forum rss-feed

Forum

Pico: 2.0.x changes and those without workbench left behind =I

Most Recent

written by: TheTechnobear

ah, i see the talker phrases are pre-compiled with connections, that makes alot of sense.
but still, importing rig is no different from adding a rig and subsequent components in WB... for this operation, the talkers would also (under current implementation) need 'recompiling'

i can see for a pluggable rig changeable at performance time, this would be inefficient/undesirable and you would need to abstract these connections ... and therefore how you would get then to the idea of 'talker ports' or similar. as you first mentioned, though this then brings up a whole raft of other interesting issues.

hmm, definitely something I will take a look into later :)


so do you guys manually duplicate the rigs within the factory setups? or do you something like hack the setup file?

The reason I was asking all this, is I want to create a setup which basically was like the factory setup, but had you mod synth in each rig, I was then going to tailor each mod synth a bit.
I know i can do this all manually in workbench, but then thought 'wouldnt it be nice to copy/paste, import/export rigs'.
anyway will do manually for now, as have some interesting ideas i want to play with :)


source code, im fine thanks, basically along with the videos, seems to be pretty clear, i seem to be able to find my way around it, only occasionally getting a bit lost in the python (which is not really my thing :)), think my next step will be to build a simple agent - but i think I should get back to improving my playing skills!





written by: TheTechnobear

Thu, 17 Jan 2013 15:28:41 +0000 GMT

@john, thanks for the explanation... i kind of get it, but am also a bit confused (easily done, especially as im new to this eigenharp world :))

k, i understand that the talkers (or interpreter) cuts across the wired up world. id assumed it did so by using a std observer model on agents, and building its own 'model' of the world and then could talk to agents directly - and so bypass the rig all together.
but im a little confused to why this affects import/export of rigs?
surely, as we import a rig, it just brings in new components, as if you were creating in WB, and so then they would become available to talkers (as the create events are broadcast).

Of course, im making alot of assumptions about talkers & rigs not serializing agents addresses.

From a user perspective, Im assuming, that whilst a user could import a rig, it wouldnt do anything until it was wired up, and potentially some of the talkers altered appropriately (as some talkers in the setup explicitly refer to the rig names) ... but thats ok for step 1 - no?


Unfortunately, its probably a bit early for me to contribute coding effort, as im still very much trying to understand the eigenharp world, and only recently been digging through the source code (& dev videos). But contributing later, is something I would be interested in.





written by: john

Thu, 17 Jan 2013 16:16:21 +0000 GMT

In order for Talkers to be able to execute in a timely manner (ie, to be processed within one audio buffer of being invoked), which is one of the great things about them, they have to effectively be 'pre-processed', so the Belcanto is not actually evaluated at the time of execution, it's parsed and processed when the Talker is edited. Connections to the needed actions in all the Agents that phrase affects are then established in the background, so the phrase can be executed. If you use Belcanto from scratch (as in from the Commander) then it is not intrinsically timely as the phrase must be parsed, all the Agents must be found etc. This is neither speedy or deterministic, making it unsuitable for things where you need them done at that very moment. Sometimes you'll be fine, but sometimes you might miss your timing if the machine is busy or the command affects a lot of Agents, so it is inherently jittery, which is not good for performance. Pre-evaluation prevents this at the cost of introducing difficulty whenever setups are changed as many of the great Belcanto things involve multiple Agents, and they may or may not be there after a change. Hence the issue when a Rig comes and goes. If it has a scaler inside then the Talker must be re-evaluated to 'see' that scaler, and commonly used Belcanto in a Talker like 'all scale to x set' silently and mysteriously stop working. That's the kind of behaviour that makes me shudder as we end up having to field the (justifiably) annoyed user emails that come from it.

When I refer to a 'pluggable rig' I'm actually talking about something a bit more useful than being able to simply import them in Workbench, I'm referring to being able to insert and remove a Rig into a Rig Host while EigenD is running, rather as you can use VST's or AU's in a DAW. I think this is probably a much more useful piece of functionality, and not far off the same level of difficulty as one still has to solve many of the same problems, namely with Talkers.

If you need any help at any time figuring out the source code, please get in touch and we'll do our best to help..

John


written by: NothanUmber

Thu, 17 Jan 2013 18:04:07 +0000 GMT

Still not sure whether I already "got" all implications.
Would it be possible to easily implement rig import/export by introducing the following restrictions:
talkers can neither
- reference anything inside a rig (only non-rig elements on the root level)
- be part of a rig (they can only be placed at the root level themselves - perhaps it would even still be possible to allow talkers inside rigs and the only restriction necessary would be that they can just reference agents on the same level as the talker itself?)

This would introduce an incompatibility to existing projects (depending on whether they violate those rules or not).
Talkers could still influence rigs but only by manipulating other agents that explicitly send the information into the rig via a (visible) wire. So most things should still be achievable - just some restrictions on the "how" less on the "what".
*edit*: At least if the only restriction necessary would be that talkers can only influence agents at the same level there should be a "refactored" project for all currently possible projects - at least manually. Doing that via a "clever" import script (so the new EigenD version would even be downwards compatible again) might be nontrivial though - e.g. for talkers whose phrases reference agents on different levels and thus would have to be split then into several talkers on different levels...

If a more sophisticated rig import and export solution should come into existance at some point the restrictions can be removed again. This time it wouldn't be an incompatible change.

On first sight I personally would prefer having an import and export feature while taking the restriction into account. (Asuming the feature can easily be implemented then).
Other opinions?

Greetings,
NothanUmber


written by: TheTechnobear

Thu, 17 Jan 2013 17:59:28 +0000 GMT

ah, i see the talker phrases are pre-compiled with connections, that makes alot of sense.
but still, importing rig is no different from adding a rig and subsequent components in WB... for this operation, the talkers would also (under current implementation) need 'recompiling'

i can see for a pluggable rig changeable at performance time, this would be inefficient/undesirable and you would need to abstract these connections ... and therefore how you would get then to the idea of 'talker ports' or similar. as you first mentioned, though this then brings up a whole raft of other interesting issues.

hmm, definitely something I will take a look into later :)


so do you guys manually duplicate the rigs within the factory setups? or do you something like hack the setup file?

The reason I was asking all this, is I want to create a setup which basically was like the factory setup, but had you mod synth in each rig, I was then going to tailor each mod synth a bit.
I know i can do this all manually in workbench, but then thought 'wouldnt it be nice to copy/paste, import/export rigs'.
anyway will do manually for now, as have some interesting ideas i want to play with :)


source code, im fine thanks, basically along with the videos, seems to be pretty clear, i seem to be able to find my way around it, only occasionally getting a bit lost in the python (which is not really my thing :)), think my next step will be to build a simple agent - but i think I should get back to improving my playing skills!







Please log in to join the discussions