Forum rss-feed

Forum

Software: Project: Complete connectivity diagrams of the EigenD setups

Most Recent

written by: NothanUmber

Thanks John and 0beron for the heads up, these sessions are really a nice and helpful idea!

Can this session only be seen live once or will a recording be posted for later viewing? (Otherwise if I can't be there at friday night I could place the MacBook in front of the LCD and start foto booth :P )

According to the Keygroups description, courses can indeed be defined within one keygroup - nice! (Initially I thought we'd need hierachical keygroups for that) Will have to see whether multiple courses actually bring an advantage in my special case as I don't actually need offsets > 1 between the "strings". On second thought presumably one "monstercourse" will be sufficient).
Still do not see from the description how to swap roll and yaw axis without the Plumber and knowledge about the connection between the keygroup and (presumably...) the recorders (or whatever might be in between...) and I am a little bit worried about making the menus unusable as 0beron described, hope there is a way to circumvent that.
Looking forward to the session with great anticipation! :)

Greetings,
NothanUmber

written by: NothanUmber

Sun, 3 Oct 2010 02:24:54 +0100 BST

Hi,
imho the most important thing that is missing in order to make use of the Belcanto system is the knowledge about the internal connections of the EigenD default setups.
Some infos can be guessed, some things are splattered around in the wiki - but many aspects are still unknown.

Asking the support I always was referred to the imminent release of the Workbench that would uncover everything. As this Workbench seems to have moved further into the future again (not being released as part of the 1.X series anymore) perhaps it would be worthwile to collect what we already know in order to be able to get productive with Belcanto itself in the mean time. Perhaps we can get together more pieces of the puzzle.

(Although the Tau setup will be the one where I am most interested in in the long run (because I want to do some substantial changes) I started to collect everything I found about the Pico first (simply because I already have a Pico and because this seems to be the setup where most information is available - and it is the simplest.)

I started to put together everything I could find from the wiki about the Pico default setup 1, many things are guesswork though (so most presumably a lot of the info is wrong). (Unfortunately there does not seem to be any kind of (documented) introspection capability - a way to "ask" the network how it is set up - this would help tremendously)

If somebody has further infos: Please add them to the spec, would be greatly appreciated! If it is more stable we could even put it in the wiki (didn't want to do it in the current state as almost everything in the wiki is from Eigenlabs, so people expect that the information there is correct.)

In order to allow everybody to edit the layout and not having to think too much about layout I was happy to find a web page that translates a textual description in an easy to comprehend format into a diagram. (Initially it is meant for UML diagrams but it seems to do the job in this case, too :) ) In order to see the diagram just copy the text below into the edit field of this page:
http://yuml.me/diagram/scruffy/class/draw
and press "generate diagram". (If the diagram should become more stable we could just save the picture/pdf into the wiki so that the poor server doesn't have to recalculate it every time)

The diagram is meant to be read in the following way:
a line with the format
"inputnr:outputport[/inputport]" means that the inputport of the agent that contains the description is connected to the outputport of the preceding agent with number inputnr (if an agent has only one input-delivering agent then this nr. is always 1. The role of the input-delivering agents can be found on the incoming connector lines. If the input port has the same name as the output port that it is connected to (which seems to be quite normal) then the name of the input port is not explicitly specified).
E.g. "2:pressure" in the "Cycler 1" agent means that pressure output of "Scaler 2" (which is input 2 to the cycler 1) is connected to the pressure input of cycler 1 and "3:volume/feedback" means that the volume output of ahdsr 1 is used as feedback input of cycler 1.

Greetings,
NothanUmber

P.S.: Sometimes the yUML page seems to hang, if the diagram doesn't come up after about half a minute, press "generate diagram" again, most of the time the diagram appears after a few seconds then.
P.P.S.: Don't add empty lines between, before or after the text, yUML doesn't seem to like that, if the diagram does not appear that could be reason.
P.P.P.S.: The forum software seems to eat everything between "" for breakfast, so bidirectional links were invisible, changed that to to unidirectional links now

#Keygroup
[KGroup 1]->[Recorder 1]
[KGroup 1]->[Recorder 2]
[KGroup 1]->[Recorder 3]
[KGroup 1]->[Recorder 4]
[KGroup 1]->[Recorder 5]
[KGroup 1]->[Recorder 6]
[KGroup 1]->[Recorder 7]
[KGroup 1]->[Recorder 8]
#Sampler 1
[Recorder 1]1->[Scaler 1|1:controller;1:strip position/global pitch bend;1:pressure;1:yaw;1:roll/k pitch bend;1:activation]
[Recorder 1]1->[Cycler 1|1:pedal/damper pedal;2:scale note;2:pressure;2:yaw;2:roll;2:activation;2:frequency;3:volume/feedback]
[Scaler 1]2->[Cycler 1]
[Cycler 1]1->[AHDSR 1|1:damper;1:pressure/pressure1;1:pressure/pressure2;2:delay;2:attack;2:hold;2:decay;2:sustain;2:release;2:envelope/activation]
[AHDSR 1]3->[Cycler 1]
[Cycler 1]1->[Sampler Oscillator 1|1:frequency/frequency1;1:frequency/frequency2;2:activation{bg:orange}]
[Sampler Oscillator 1]2->[AHDSR 1]
[AHDSR 1]2->[Sampler Oscillator 1]
[Sampler Oscillator 1]1->[Gain 1|1:left audio;1:right audio;2:volume]
[AHDSR 1]2->[Gain 1]
[Gain 1]1->[Summer 1|1:audio]
[Summer 1]->[Audio Unit 6]
[Audio Unit 6]->[Console Mixer 1]
#Sampler 2
[Recorder 2]1->[Scaler 2|1:controller;1:strip position/global pitch bend;1:pressure;1:yaw;1:roll/k pitch bend;1:activation]
[Recorder 2]1->[Cycler 2|1:pedal/damper pedal;2:scale note;2:pressure;2:yaw;2:roll;2:activation;2:frequency;3:volume/feedback]
[Scaler 2]2->[Cycler 2]
[Cycler 2]1->[AHDSR 2|1:damper;1:pressure/pressure1;1:pressure/pressure2;2:delay;2:attack;2:hold;2:decay;2:sustain;2:release;2:envelope/activation]
[AHDSR 2]3->[Cycler 2]
[Cycler 2]1->[Sampler Oscillator 2|1:frequency/frequency1;1:frequency/frequency2;2:activation{bg:orange}]
[Sampler Oscillator 2]2->[AHDSR 2]
[AHDSR 2]2->[Sampler Oscillator 2]
[Sampler Oscillator 2]1->[Gain 2|1:left audio;1:right audio;2:volume]
[AHDSR 2]2->[Gain 2]
[Gain 2]1->[Summer 2|1:audio]
[Summer 2]->[Audio Unit 7]
[Audio Unit 7]->[Console Mixer 1]
#Sampler 3
[Recorder 3]1->[Scaler 3|1:controller;1:strip position/global pitch bend;1:pressure;1:yaw;1:roll/k pitch bend;1:activation]
[Recorder 3]1->[Cycler 3|1:pedal/damper pedal;2:scale note;2:pressure;2:yaw;2:roll;2:activation;2:frequency;3:volume/feedback]
[Scaler 3]2->[Cycler 3]
[Cycler 3]1->[AHDSR 3|1:damper;1:pressure/pressure1;1:pressure/pressure2;2:delay;2:attack;2:hold;2:decay;2:sustain;2:release;2:envelope/activation]
[AHDSR 3]3->[Cycler 3]
[Cycler 3]1->[Sampler Oscillator 3|1:frequency/frequency1;1:frequency/frequency2;2:activation{bg:orange}]
[Sampler Oscillator 3]2->[AHDSR 3]
[AHDSR 3]2->[Sampler Oscillator 3]
[Sampler Oscillator 3]1->[Gain 3|1:left audio;1:right audio;2:volume]
[AHDSR 3]2->[Gain 3]
[Gain 3]1->[Summer 3|1:audio]
[Summer 3]->[Audio Unit 8]
[Audio Unit 8]->[Console Mixer 1]
#Audio Unit 1
[Recorder 4]->[Scaler 4]
[Scaler 4]->[Audio Unit 1{bg:orange}]
[Audio Unit 1]->[Summer 4]
[Summer 4]->[Audio Unit 9]
[Audio Unit 9]->[Console Mixer 1]
#Audio Unit 2
[Recorder 5]->[Scaler 5]
[Scaler 5]->[Audio Unit 2{bg:orange}]
[Audio Unit 2]->[Summer 5]
[Summer 5]->[Audio Unit 10]
[Audio Unit 10]->[Console Mixer 1]
#Cello
[Recorder 6]->[Stringer 2]
[Stringer 2]->[Scaler 9]
[Scaler 9]->[Shaper 2]
[Shaper 2]->[Cello Oscillator 5{bg:orange}]
[Cello Oscillator 5]->[Gain 5]
[Gain 5]->[Summer 8]
[Summer 8]->[Convolver 1]
[Convolver 1]->[Audio Unit 11]
[Audio Unit 11]->[Console Mixer 1]
#Clarinet
[Recorder 7]->[Stringer 1]
[Stringer 1]->[Scaler 7]
[Scaler 7]->[Shaper 1]
[Shaper 1]->[Ranger Agent 1]
[Ranger Agent 1]->[Clarinet Oscillator 4{bg:orange}]
[Clarinet Oscillator 4]->[Gain 4]
[Gain 4]->[Summer 7]
[Summer 7]->[Audio Unit 12]
[Audio Unit 12]->[Console Mixer 1]
#MIDI Output 1
[Recorder 8]->[Scaler 8]
[Scaler 8]->[MIDI Controller 1]
[MIDI Controller 1]->[MIDI Converter 1]
[MIDI Converter 1]->[MIDI Output 1{bg:orange}]
#Master Output
[Console Mixer 1]->[Delay 1]
[Delay 1]->[Audio Unit 3]
[Audio Unit 3]->[Audio Unit 4]
[Audio Unit 4]->[Audio 1]


written by: Tenebrous

Sun, 3 Oct 2010 12:25:29 +0100 BST

I think that's what we're missing, and would definitely help - a big diagram showing everything just like you have done there!

For info, I use Google Docs for drawings, seems to work pretty well and is shareable with other people who can also make edits, and can be embedded in various places via an HTML img tag :)

I'm also thinking (hoping) that the Workbench provides this kind of graphical layout :)


written by: NothanUmber

Sun, 3 Oct 2010 14:20:13 +0100 BST

Well I hope to attract some old time community members who had the chance to visit Eigenlabs or got additional infos in private mails that helped them with their specific setups to share the knowledge. I still wonder why we don't have something like that from Eigenlabs as it shouldn't be too much work and would presumably answer a relevant percentage of the "power user questions" that their support has to cope with now.
As we don't know when the Workbench will arrive it is difficult for the "outsiders" to estimate whether this project is "worth it" (always presuming that the Workbench will expose all the details we need.) If the workbench will be released within the next weeks - probably not, if it will happen within the next 2-6 months, definitely, yes!

Really hope somebody with the knowledge jumps in! (Geert perhaps? He would be a perfect candidate as he was in a similar situation as we for a long time, surely has the knowledge about the setup structure now and could estimate whether it's worth the effort. Hope he would be allowed to share the information if he wanted though...)

Perhaps it could be as easy as providing a few screenshots of the Workbench for each setup that cover all the informations? Filling in the remaining details in something like the yUML format should also be manageable, learning how to use the tool and putting in the infos from the wiki took me only a few hours. (The main time went into jumping back and forth between the information sources in the wiki... ;) )

Regarding Google Docs, I had a look at it while searching for a tool to use but didn't find a way to connect lines to boxes, so if you move a box you have to manually correct all edges, too. So this could become a layout nightmare for more complex setups. Or is Google Docs/Drawings capable of this and I just didn't find it? (The other web based vector graphic tools and case tools I found required a registration which seems to be not practical for this purpose)
(The first version of the diagram was done just for myself with Enterprise Architect, if someone prefers it in that format then I can gladly share the eap file, just ask.)

Greetings,
NothanUmber


written by: john

Sun, 3 Oct 2010 17:50:56 +0100 BST

Hi NothanUmber, Tene

As it stands at the moment, the new Workbench doesn't look that far off, certainly in an initial unstable release. In order to explain the big issue with it (and why it is not going to be in the new 1.2 Unstable line but is being kept back for the 2.X line) it is probably useful to give you a little history. It's not for lack of work or desire on our part that it is not yet released, it's a genuinely hard problem that has taken us some time to solve.

We did actually have a configuration tool in house that was in use right up until late last year. You could think of this is our original 'Workbench'. Some elements of this made their way into the current EigenD UI, notably the Commander and Browser were panes from that tool. There were also panes that showed a graphical view of the whole system, drawn as a connected graph of Agents, and an 'Inspector' that allowed one to see the connections to and from one Agent. This, to everyone who has played around with configuring EigenD, probably sounds like just what you need. The main graphical overview was in fact very much what is being mentioned here. Several early players saw this tool in London last year.

Interestingly (and very annoyingly if you are me) it turned out to almost useless, for a reason that wasn't obvious when we wrote it and only became apparent later (the useful bits mostly ended up in our current UI, with the exception of the inspector view, which I suspect would be useful but is very shortly to become rather redundant and so is probably not worth the work to incorporate it).

The simple reason that the graphical tool became unusable was that it was a display only. It relied on being smart to draw the Agents and connections nicely. Now as EigenD was originally imagined this made sense. We thought that we'd have a few dozen Agents, fairly simply connected. By the time we reaised how useful it was to have very small Agents (meaning we ended up with a LOT of them in an average setup) it was too late to change the way we did this before launch. Current setups have hundreds of Agents (often 4-5-600) and literally thousands of connections between them. Making this into a comprehensible, usable diagram automatically proved impossible, as people who saw the rather frightening old Workbench might testify.

It took us quite a while to realise that the only solution to this was to make the graphical arrangement of that diagram a user editable thing. This has some implications that are rather more profound that just enabling boxes to be dragged around a canvas. Not only will players expect to be able to configure and plumb the system within the tool (which is a major addition to the process that is currently used, which is purely linguistic) but they will also expect it to look good and be, above all, tidy and comprehensible. This requires quite a bit of additional data in the system to support the nice graphical arrangement, data that has to be added to every connection and Agent. When one looks at the difficulty of doing this, it actually makes much better sense to rebuild all the current setups in the new tool so that this data is consistently there, and the setups can be displayed well, in a comprehensible and editable fashion. This means that all the current Factory Setups will be replaced with new setups, which may be different from the previous setups in a number of ways.

This is the principle (though not only) reason that Workbench will not be in the new 1.2 branch. We didn't want to lose backwards compatibility of setups in 1.2 as it is a release that will have a number of important feature additions that gigging musicians have requested (who are all using setups with various degrees of customisation and some of whom are mid tour, rehearsal or recording with these setups), along with the stabilisation and release of Windows, which is an important and pressing objective for us.

To answer your question, 'is it worth the trouble to produce a diagram of the factory setups?' I would say probably not. Workbench really is not that far away (Al, who is the main developer for it here, actually suggested last week that we started using it to produce connection diagrams for the seminars, so he's feeling pretty good about its prospects) and the we did already consider doing just that a while ago here and decided it was going to quite a substantial effort (a decent diagram of Alpha Factory 3 would be a very large thing) for little real gain, except in the very short term. In case you're wondering, we've already played with several of the automatic connection graph drawing tools with disappointing results I have to say.

It's a tricky problem, and I'm sorry that the fix is taking so long, but I do think it will be worth the wait. You may start to see some screenshots from Workbench very soon, illustrating the seminars.


John


written by: NothanUmber

Sun, 3 Oct 2010 19:15:56 +0100 BST

HI John,

thanks for this detailed reply!

This "Inspector" would have been the key view that I hoped for from the beginning. I can understand that you don't want to put effort into this anymore at this point with the "successor" around the edge.

Some infos why this is so important to me:
For the Pico it is not that grave (mainly I wanted to change the way how controller messages are translated into MIDI messages in the Pico Setup for the Audio Unit slots in order to be able to use per key pitch/roll/yaw)

For the Tau it will be more important because I want to change the key layout to a horizontal setting of 16 courses with 4 notes each (highest note at the upper right, each note occurs only once) in order to play chromatically over more than five octaves. (I can imagine that the alternative 7 note scales are good for compositional "learning lessons" as you need to think how to change base note and scale in order to get the notes for certain complex chords but for intuitive play it seems too limited so I don't want to part from the familiar 12 note chromatic scale as default :) )
Beside the basic layout change that would include swapping the destinations for roll and yaw on various(?) places in order to have vibrato on the horizontal axis (because of the supposed matching playing position with arms parallel to the instrument, left hand up, right hand down).
Before doing this layout change it makes little sense to seriously practice as the default setup substantially differs from the one I plan to use.

So I look forward to the new Workbench and continue to search for matching sounds in the mean time.

Greetings,
NothanUmber


written by: john

Sun, 3 Oct 2010 21:40:17 +0100 BST

Hi NothanUmber

Actually, I don't think Workbench will help you with either of those two things. I'm not sure quite what you mean by the first one (for the Pico), but the second is related to Keygroup layout, not routing. This is actually done in a different way. I'll see if we can schedule a seminar topic in the next few weeks to cover this - it's a common request to change and adapt the key order and course layout, and not that difficult to do once you're shown how.

We will be improving the MIDI translation matrix for Au's shortly, probably in 1.2 - that may provide the facility you are looking for.

John


written by: NothanUmber

Sun, 3 Oct 2010 22:10:30 +0100 BST

Hi John,

thanks again for taking the time!
I thought I'd need to understand the connections of the Tau setup for swapping roll and yaw at various places and to introduce new courses but if this can be done just with the Keygroup, this is very good news! Will start to experiment a little with the keygroup agent when my Tau arrives and look forward to the seminar, would be really great!

Regarding the Pico: I mainly wanted to change two things on the Audio Unit MIDI settings:
* the yaw axis should generate modulation (CC1+CC33) like the midi out module already does
* the pressure axis should output aftertouch in addition to note on velocity (as it already seems to be the case with the Alpha as far as I understood)
Currently I use the parameter automation feature of the EigenD Audio Unit agent to retrieve these informations but that way key/channel information is missing, so modulation and aftertouch always affect all notes in parallel.

Greetings,
NothanUmber


written by: 0beron

Mon, 4 Oct 2010 09:58:30 +0100 BST

I've experimented with keygroup layout (the way to do it is hidden in the wiki: http://eigenlabs.com/wiki/Keygroups/ ). I remapped my Alpha so that each course ran in a circle of fifths much like the bass rows on an accordion. The trouble is that this seems to move the key numbers, and so all the nice menus you expect to see when you press the keygroup mode key get scattered across the keygroup, making them impossible to use. We'll need the workbench to put all the menu talkers back in the right place perhaps?


written by: john

Mon, 4 Oct 2010 21:53:52 +0100 BST

Hi NothanUmber

Just to let you know that it looks like Dave is going to covering Alpha and Tau Keygroup layout in this weeks seminar on Friday evening (it's been moved from Thursday as he has a support commitment for a TV show).

John


written by: NothanUmber

Mon, 4 Oct 2010 22:43:07 +0100 BST

Thanks John and 0beron for the heads up, these sessions are really a nice and helpful idea!

Can this session only be seen live once or will a recording be posted for later viewing? (Otherwise if I can't be there at friday night I could place the MacBook in front of the LCD and start foto booth :P )

According to the Keygroups description, courses can indeed be defined within one keygroup - nice! (Initially I thought we'd need hierachical keygroups for that) Will have to see whether multiple courses actually bring an advantage in my special case as I don't actually need offsets > 1 between the "strings". On second thought presumably one "monstercourse" will be sufficient).
Still do not see from the description how to swap roll and yaw axis without the Plumber and knowledge about the connection between the keygroup and (presumably...) the recorders (or whatever might be in between...) and I am a little bit worried about making the menus unusable as 0beron described, hope there is a way to circumvent that.
Looking forward to the session with great anticipation! :)

Greetings,
NothanUmber



Please log in to join the discussions