app emulator

[catfact]

make an aleph application emulator library.

this would be provide everything that apps would take from avr32_lib

• [ ] screen
• [ ] timers
• [ ] event queue
• [ ] UI input
• [ ] serial data

and then link app code directly.

[catfact]

have made projects at aleph/utils/avr32_sim and aleph/utils/beekeep

avr32_sim is just a copy of avr32_lib with most of the function definitions PPd out. need to flesh out simulation hooks for the functions that are actually called by bees, and remove the rest.

the 'beekeep' application compiles and links the bees sources directly, and runs an instance of a network in linux. this can be used for editing patches both online and off as well as developing operators.

[tehn]

whoa, offline operator development. this is huge.

On Tue, Jan 21, 2014 at 9:05 PM, ezra buchla notifications@github.comwrote:

have made projects at aleph/utils/avr32_sim and aleph/utils/beekeep

avr32_sim is just a copy of avr32_lib with most of the function definitions PPd out. need to flesh out simulation hooks for the functions that are actually called by bees, and remove the rest.

the 'beekeep' application compiles and links the bees sources directly, and runs an instance of a network in linux. this can be used for editing patches both online and off as well as developing operators.

— Reply to this email directly or view it on GitHubhttps://github.com/tehn/aleph/issues/164#issuecomment-32957462 .

[catfact]

well its still a decent amount of work to go through and :

a) identify all avr32_lib and ASF functions that bees has to call b) identify data structures declared in avr32_lib and used by

all the functions in a) would have to be implemented in avr32_sim and have reasonable results. maybe it's possible to provide python hooks or something; i don't know enough about how to do that though.

if i were to do this in C i would probably just make an OSC server for the UI, using liblo.

as it is: there are very few lib functions implemented. i can watch the unpickling process on a scene file, before it tries to query the blacfkin and promptly segfaults. still, better than nothing..

On 01/21/2014 02:36 PM, brian crabtree wrote:

whoa, offline operator development. this is huge.

On Tue, Jan 21, 2014 at 9:05 PM, ezra buchla notifications@github.comwrote:

have made projects at aleph/utils/avr32_sim and aleph/utils/beekeep

avr32_sim is just a copy of avr32_lib with most of the function definitions PPd out. need to flesh out simulation hooks for the functions that are actually called by bees, and remove the rest.

the 'beekeep' application compiles and links the bees sources directly, and runs an instance of a network in linux. this can be used for editing patches both online and off as well as developing operators.

— Reply to this email directly or view it on GitHubhttps://github.com/tehn/aleph/issues/164#issuecomment-32957462 .

— Reply to this email directly or view it on GitHub https://github.com/tehn/aleph/issues/164#issuecomment-32972191.

[catfact]

"beekeep" is working with a JSON library attached, so can dump machine/human-readable representations of the network state, and also read them back.

[ghost]

Hi Guys was wondering if you could offer some guidance how to move forward making beekeep actually do some new stuff. I've collected my progress on my fork in branch called beekeep_network. I did some research last week into python hooks/callbacks and created a simple gui app to learn how to:

a. crudely simulate the front panel controls on aleph using python tk library b. call C functions in shared object from python c. setup python callbacks from the shared object

Already thinking maybe would be better to embed python interpreter in the C program - any insight?

After some gentle prodding of the beekeep code I stopped it segfaulting when reading in certain networks from json, so I can convert a scene, e.g default.scn to and from json with a version of beekeep built against fairly recent bees code. But struggling to see the way forward. Any pointers you could offer would be greatly appreciated!

[catfact]

sounds good!

need to clarify a little what you mean by "fairly recent," etc. the scenes in latest zip as of now are built with bees 0.4.3. so to convert those with beekeep you must built beekeep against that version of bees, and not any other. if you build it from HEAD of the dev branch, that is currently 0.5.0.

i don't get segfaults or anything so if there is something really wrong i would like to see the scene file that triggered it and a call stack from GDB. but i suspect it is a version mismatch.

i'll put some time into this over this weekend (today is march 20) ; the 'beekeep' branch in the repo is there specifically to keep track of new changes in beekeep code (e.g. in the json schema) while keeping it independent of the bees code (which dictates the actual binary format of .scn files). i need to give it a little attention to make sure i can convert demo scenes from 0.4.3 for the upcoming release of 0.5.0.

hope that makes sense.

On 03/19/2014 06:00 PM, rick wrote:

Hi Guys was wondering if you could offer some guidance how to move forward making beekeep actually do some new stuff. I've collected my progress on my fork in branch called beekeep_network. I did some research last week into python hooks/callbacks and created a simple gui app to learn how to:

a. crudely simulate the front panel controls on aleph using python tk library b. call C functions in shared object from python c. setup python callbacks from the shared object

Already thinking maybe would be better to embed python interpreter in the C program - any insight?

After some gentle prodding of the beekeep code I stopped it segfaulting when reading in certain networks from json, so I can convert a scene, e.g default.scn to and from json with a version of beekeep built against fairly recent bees code. But struggling to see the way forward. Any pointers you could offer would be greatly appreciated!

— Reply to this email directly or view it on GitHub https://github.com/tehn/aleph/issues/164#issuecomment-38125551.

[c1t1zen1]

Yes that makes sense.

K

On Thu, Mar 20, 2014 at 7:26 PM, ezra buchla notifications@github.comwrote:

sounds good!

need to clarify a little what you mean by "fairly recent," etc. the scenes in latest zip as of now are built with bees 0.4.3. so to convert those with beekeep you must built beekeep against that version of bees, and not any other. if you build it from HEAD of the dev branch, that is currently 0.5.0.

i don't get segfaults or anything so if there is something really wrong i would like to see the scene file that triggered it and a call stack from GDB. but i suspect it is a version mismatch.

i'll put some time into this over this weekend (today is march 20) ; the 'beekeep' branch in the repo is there specifically to keep track of new changes in beekeep code (e.g. in the json schema) while keeping it independent of the bees code (which dictates the actual binary format of .scn files). i need to give it a little attention to make sure i can convert demo scenes from 0.4.3 for the upcoming release of 0.5.0.

hope that makes sense.

On 03/19/2014 06:00 PM, rick wrote:

Hi Guys was wondering if you could offer some guidance how to move forward making beekeep actually do some new stuff. I've collected my progress on my fork in branch called beekeep_network. I did some research last week into python hooks/callbacks and created a simple gui app to learn how to:

a. crudely simulate the front panel controls on aleph using python tk library b. call C functions in shared object from python c. setup python callbacks from the shared object

Already thinking maybe would be better to embed python interpreter in the C program - any insight?

After some gentle prodding of the beekeep code I stopped it segfaulting when reading in certain networks from json, so I can convert a scene, e.g default.scn to and from json with a version of beekeep built against fairly recent bees code. But struggling to see the way forward. Any pointers you could offer would be greatly appreciated!

Reply to this email directly or view it on GitHub https://github.com/tehn/aleph/issues/164#issuecomment-38125551.

Reply to this email directly or view it on GitHubhttps://github.com/tehn/aleph/issues/164#issuecomment-38243523 .

[ghost]

OK so yeah this was a case of version mismatch so thanks for straightening that out. I built beekeep-0.4.3 against master, then was able to convert default.scn from latest zip to and fro json.

Went to build beekeep-0.5.0 against dev, which was refusing to compile. After fixing that was able to convert the json to/fro 0.50 scn format without the weird segfaults.