written by: Nathan
Hi There, All,Yep, I agree. A little more explanation of the key layouts, physical and musical, for the keygroups would be appreciated. I was also a little surprised to see negative numbers when poking through the partial factory setup in the recent release, though I think I understand what's going on.
I think that's a shorthand for positioning things at the end of a keygroup, a bit like python list indexing, ie a -1 means 'whichever is the number at the end of this list' and -2 means the last but one etc.
That may be true, but the tutorials and workbench docs shouldn't assume familiarity with the python list indexing ;-)
This set of features is very new and we're still waiting for the dust to settle before we update the documentation. We're not totally sure that it's all correct as yet and are waiting until we've finished building the existing Factory setups in 2.0 to be sure - there's nothing like building those to find out if there are any errors. The full separation between physical and musical coordinate systems was only completed last week just before the most recent release, so you can see how new it all is. If it looks good we'll add some documentation shortly, and I believe that Al has a tutorial in mind at some point. Right now it's still subject to 'change without notice' though, so please keep that in mind as you explore. We'll make sure to indicate any such changes in the release notes.
0beron, you're correct, the negative coordinate numbers are in fact a way of indicating that you'd like the coordinates to be taken from the far end of the layout rather than the origin - this is very useful when laying out talkers amongst other things - one can make a group that is consistently started from the bottom of a Keygroup for example - very useful on the Alpha. This is an idiom we intend to try and make general throughout EigenD in time.
I agree that the row/column names might be confusing - I'll discuss this with the team in Wednesday. It's a pretty arbitrary way round and if it's easy to change we'll look into it.
John
Yep --- that just confused the hell out of me too.
Is it just me, or is anyone else confused by the row/column distinction in Workbench? Particularly on the Tau and the Alpha, what I would consider a column (ie a course of 24 keys on the Alpha) is actually a row in workbench and vice-versa. Not a big problem but might cause people a headache.
[deleted]
Hi, I've added a couple of new tutorials to the Workbench Building Your First Setup From Scratch series here today. They describe how to add a Talker Agent and a Controller Agent to your first simple setup.
These tutorials were written using the 2.0.50 release (just released today) in which the property editor in workbench has a significantly improved layout. In older releases you won't see exactly the same dialogs but it should all still work.
Feedback welcome as always.
Alistair
New tutorials are great. Slowly opening up the possibilities.
Happy also that 2.0.50 has a stable format of setups. Will be great to be able to start sharing setups to see how others are accomplishing things.
Randy
How do I replicate a complicated rig I've built? Or copy it to another setup? I see no way of saving the contents of a tab, as I can with Stage. That is, short of save-as a separate setup, having pruned everything except the rig, and then building a new setup from scratch round it.
Do I really have to construct the whole rig again in an empty rig agent, remembering exactly what I did?
More generally, I see no copy/paste in the Edit menu. A way of copy/pasting agents (if the editing has been complex) - maybe even blocks of agents plus their wiring - would be dandy.
If that's too hard to implement, then how about merging 2 setups? Agents would of course have to be renamed to resolve name clashes. Or simply warn of duplicate names, abort, and leave it to the user to rename the offending agents?
i raised this, in this thread
http://www.eigenlabs.com/forum/threads/id/1210/
and john replied, so you might want to check out the response.
the short answer is, its a known feature request.... but not that simple, for the reasons given by john.
Hack only - ymmv
Setups have rigs saved in a separate file eg user setup 1#rig1
what I've done, is created an empty rig in another setup using workspace
and then copy an existing rig over this file.
Then reload the setup and the new rig is loaded :)
Note it messes up the inputs on the gateway, but they can be re done easy enough
Seemed to work for me
i raised this, in this thread
http://www.eigenlabs.com/forum/threads/id/1210/
and john replied, so you might want to check out the response.
the short answer is, its a known feature request.... but not that simple, for the reasons given by john.
Hack only - ymmv
Setups have rigs saved in a separate file eg user setup 1#rig1
what I've done, is created an empty rig in another setup using workspace
and then copy an existing rig over this file.
Then reload the setup and the new rig is loaded :)
Note it messes up the inputs on the gateway, but they can be re done easy enough
Seemed to work for me
We're well aware of this hack, and I've used it myself several times. It has however a huge downside and even I, who knows the setups extremely well, has been bitten by it. Since the talkers are pre-compiled, a part of the connection is stored in the agents upon which the talkers operate. When talkers use what's in a rig (this is the same for controllers and Stage widgets btw), that part is stored in the rig. When you copy and duplicate a rig like you do, you also duplicate that part of the talker/controller connection, which ends up being dangling and can start causing all sorts of weird and unexpected behaviour as it's not symmetrical anymore. This is part of the difficulty that John tried to explain before.
So in short, while it might seem to work by copying files, really don't be tempted by doing this as it most probably will result in very weird and non deterministic behaviour later on. It's extremely labour intensive to get those dangling connections cleared out and for many agents, all you can do is recreate them. Adding proper cleaning and possibly reconnection logic for those connections is part of the work that's needed to make copy/paste work.
I have to echo Geert's comment here, but I'd like to be a bit more firm: please don't do this - your new setups will very likely eventually crash as the whole system is running in a weird state. It may take a while to happen, but it will fall over and the way Sods Law works, you will be standing in front of 1000 people at the time.
Well done figuring it out, but as we've said, this is a problem that doesn't actually have a 'quick and dirty' fix. If it were we'd have implemented something already as it would have saved vast amounts of time building the factory setups. Rest assured it's on the list of wanted features, and near the top.
John
i did label as a hack for this reason, id never use this in a performance situation - but for messing about only. ( i also diliberately went and edited all talker components outside of rig, and all compoents in rig - in an attempt to clear such hidden connections - dont know if this worked, ive meant to check with brpc and bls)
im intrigued, i understood from previous conversations the requirment of talkers in the workspace, to connect into rig, but why would you have a connection from the rig out to the container?
( assuming you dont have talkers within the rig)
background, i stumbled on this, because ive been looking at the source, and was intrigued at the workspace within agentd and the rig, and the similarity of load/save code... and getting aquainted with the 'fix up' held in the agentd code so was wondering how defensively it was coded :)
Hi All,
I think this is my first post to the Eigenlabs Community.
I've (finally), recently upgraded EigenD (to 2.0.74-stable). And so, I am beginning to explore the Workbench Tutorials (for use with my Pico). But sadly, I've run in to a problem, rather early on, and am hoping someone might be able to get me back on track.
So, despite my considerable inexperience and lack of knowledge, I was able to follow the first 2 Tutorials with relative ease, and so my efforts yielded the expected results. So, kudos and much gratitude to all those who contributed such critical and informative instruction...However, unfortunately, somewhere in the 3rd tutorial, things ceased to behave/operate, for me, as described in the tutorial. Here's Where Things Went Wrong For Me: Despite (I believe) following all steps 'To a T' in creating/connecting all appropriate agents and relevant wiring for the whole of the 3rd Tutorials Setup. Things stopped working when I tried to 'test' audio from 'scaler 2', 'audio unit 2' by deleting wiring from 'keyboard pico 1' to 'scaler 1', and 'audio unit 1' and connecting the 'keyboard pico 1' to just 'scaler 2', 'audio unit 2', leaving all other connections as they were (working) from earlier. Despite things not working, I went on to complete the whole of the setup for Tutorial 3, incorporating the creation of the 'keygroup 1' and setting up/assigning the mode switch key, hoping that things would be realized and work by the end. The lights operate as expected, illuminating the proper colors, when switching (green and/or red) or holding down the assigned mode key (flashing orange), but curiously, the mode key does still emit instrument 1 sound when touched, even while flashing orange. I can't (thus far) successfully produce sound for a second instrument at all. It seems, it doesn't make a difference whether I isolate the instruments (enabling them one at a time) or attempt to enable both simultaneously (as layered, 1 and 2) with or without the presence of the 'keygroup 1'.
Unfortunately, I haven't had success sorting this out. And I can't really progress further through the tutorials while things aren't operating correctly. So, I was hoping, if I shared my situation, someone with greater awareness or insight might be able to help me out. Because of my relative ignorance, I certainly haven't ruled out the possibility of 'user error', though I try to be careful and alert, and tend to be rather detail oriented, generally.
I realize, there may be lots of info needed to help diagnose the problem, but I'm not sure what is most pertinent or necessary for a possible examination. Here are some details that might be useful, if anyone cares to comment: Pico, EigenD 2.0.74-stable, Mac Pro, OS X Lion, Focusrite Saffire Pro 40, (Do I remember reading somewhere that EigenD conflicts with Automap, or was it Focusrite's Mix Control software? Can anyone confirm?), Kontakt 5, Ableton, Logic.
Sorry for the long winded query...much appreciation for any that may be able to offer some insightful input. Happy to provide more (or better?) details or description, if I have failed to be clear.
Best regards,
Nathan
Hi Nathan, A couple of questions to try to help diagnose this. Did you remember to assign an audio unit to the second instrument (in the way that is described in Tutorial 1) ?
if you reconnect keyboard pico 1 to scaler 1 does the original instrument still play?
Alistair
Nathan - If you want to send me a copy of the setup, I can take a look and see if I can help you. I don't recall having a problem with the tutorials when I did them awhile ago, but there's a lot of places where wires can get crossed,
If you want to send me the setup to look at:
carvingcode at gmail dot com
Randy
sounds like 2 things to check:
a) "Things stopped working when I tried to 'test' audio from 'scaler 2', 'audio unit 2' by deleting wiring from 'keyboard pico 1' to 'scaler 1', and 'audio unit 1' and connecting the 'keyboard pico 1' to just 'scaler 2', 'audio unit 2',"
so if you cannot connect the keyboard and get a sound, sounds like something in this 'chain' is not quite right. id try to get this working
have you set up a plugin for the second AU?
(basically the 2nd one, needs to have been setup in the same way as you setup the first, which you got working, so you can compare it the first one)
b) keygroup
if you 'edit' the keygroup, can you see the second output being enabled, i.e. does it switch correctly.
if it does, then really its just (a) is the issue.
Please log in to join the discussions
UK
