Forum rss-feed

Forum

Developers: course layout.

Most Recent

written by: TheTechnobear

My planned workaround:

ok, if I have to link up myself, this is my plan...
a) connect musical mapping into my agent from KG
b) create a keygroup_mapper_t, and apply mapping from (a)
c) get the key_filter() = return d2d_nb_t
d) use (c) d2d_nb_t(data_db_t(course, row)) will return real column.
note: (d) requires me to create a fake data_db_t for each light.

I only have to do this when the layout changes, and then can store it away for updating lights.

this process is only required where increments > 1. this is handy as it means user only has to connect musical mapping in this case.
(the issue i have here, is it needs multiple connect calls for user, as controller and light are on output level of KG, where musical mapping is on top level KG.

any thoughts on this approach from Eigenlabs?
(a bit lonely out here as a eigenD developer!)

written by: TheTechnobear

Wed, 31 Jul 2013 11:34:24 +0100 BST

Hi,

im developing another new agent called "Scale Illuminator" which lights keys according to a reference scale.
i.e. you connect to the controller input on a KG that is say in Chromatic, and give the illuminator a reference scale of C Maj, and it will light the keys of C Maj, on the chromatic scale.
All works perfectly... but ive got a small issue...!!!!

In another development, Ive created a program that creates alternative musical layouts , but changing musical mapping.
again this works fine - and also works very well with my scale illuminator.

EXCEPT, I allow the creation of a musical mapping, that jumps in 3rds (in chromatic)
so I create a mapping that does
1, 1 to 1, 1
1, 2 to 1, 3
1, 3 to 1, 5
etc...
up to
1, 22 to 1,43
(i do same for course 2 and offset by 5.0)

this plays perfectly - so far so good :o)

BUT, Ive noticed with my illuminator, i get told the course length is 22 , not 43 as expected! (i.e. the number of entries in the mapping not, then value for the course) - this means my lights only light up half the keyboard! (they are correct, but only up to where course = 22, which row 11 )

Im getting this by using the control input, and examining the 'courselen' dictionary sent over this , in the same way as scaler does.

A bit of investigation, shows that the 'tonic lights' code in scaler has exactly the same issue, will only light the first 11 rows.
it also seems to assume course length is the number of entries

at first I assumed it was down to physical, but I made sure it used a similar mapping and it continued to have the same issue.
(and looking at the code, discounts this too)|

so apart from a 'small bug' in the tonic lights on scaler....

my question, is how do i get access in an agent to the actual musical mapping? (is it on the controller input?)
it would appear this is necessary, if you are generating lights according to the notes, you would want to only generate lights for which there is a musical entry.
... id also assume this must be possible, as otherwise how does scaler work (or is it just assuming a repeating pattern over 22?)

i know as a work around , I could connect musical mapping from a KG, and parse it , but this is really not a very good approach, and id like to avoid if at all possible!








written by: TheTechnobear

Wed, 31 Jul 2013 12:57:11 +0100 BST

ok, a bit more digging in scaler...
Ive just realised that for converting notes to frequency (i.e. playing) scaler doesn't need the course layout at all, since it just converts the note supplied by KG.
so it is now no surprise this works.
its now pretty clear that the scaler tonic lights highlights the fundamental issue, downstream agents cannot see the course layout.
I think that the current implementation of sending just the course length is wrong.
if you have non consecutive courses, then # entries will not equal highest course entry,
a quick fix would be to send the highest course entry as course length, but this is not good, as the scaler would then have to set lights for entries which dont really exists.
so the real solution is to send the whole course map. i dont see this as a big issue, as the layout does not change that often, so the extra data sent is not a real issue.

Of course you could argue that musical mappings should have consecutive entries, but if that is the case, then there is no reason to have a map (as it is in KG) , you would just need at most start and end.

therefore I will 'assume' its a bug in scale tonics, and the fix is to send the course info, downstream.

@John - Generally whats the plan with bug fixes and enhancements? can we get involved?
There is no point in me fixing in my own branch, if there is no way to get these changes 'agreed' and accepted.


written by: TheTechnobear

Wed, 31 Jul 2013 14:00:33 +0100 BST

My planned workaround:

ok, if I have to link up myself, this is my plan...
a) connect musical mapping into my agent from KG
b) create a keygroup_mapper_t, and apply mapping from (a)
c) get the key_filter() = return d2d_nb_t
d) use (c) d2d_nb_t(data_db_t(course, row)) will return real column.
note: (d) requires me to create a fake data_db_t for each light.

I only have to do this when the layout changes, and then can store it away for updating lights.

this process is only required where increments > 1. this is handy as it means user only has to connect musical mapping in this case.
(the issue i have here, is it needs multiple connect calls for user, as controller and light are on output level of KG, where musical mapping is on top level KG.

any thoughts on this approach from Eigenlabs?
(a bit lonely out here as a eigenD developer!)



Please log in to join the discussions