You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hereby I would like to propose some minor changes to the interface;
@mdjurfeldt
Currently, there is no way to get info about the available ports in the config at an application which could be used to automatically instantiate it in a factory.
Use cases are any kind of plotting libraries/closed loop systems etc. But actually the info is available, its just accessible via an environment variable in a serialized format (a user library should not deal with that). Also info about the port type is missing. I think the port type should also be part of the config.
The second point is the Event callback for Event input ports. Would it be possible to make the buffer transparent to python or at least to have a callback that just returns two lists (times, senders) instead of one function call for each single spike? I guess this would be a great performance improvement!
For now I do all of this outside of MUSIC but it would be great if you agree on this and we can implement it at some point. Other features requests regarding the interface could also be linked here to develop an idea of how the interface in the next versions could look like.
The text was updated successfully, but these errors were encountered:
Yes, for Python this would be an improvement. Thanks for your suggestions.
After the 2.0 release, we will work out a new interface.
Den 31 jan. 2017 12:16 skrev "Martin Schulze" <[email protected]>:
Hereby I would like to propose some minor changes to the interface;
I am a bit unhappy how the MUSIC configuration works. Specifically there
is no way to get info about the available ports in the config at an
application which could be used to automatically instantiate it in a
factory.
Use cases are any kind of plotting libraries/closed loop systems etc. But
actually the info is available, its just accessible via an environment
variable in an unparsed format (a user library should not deal with that).
Also info about the port type is missing. I think the port type should also
be part of the config. Then a factory could do the job.
The second point is the Event callback for Event input ports. Would it be
possible to make the buffer transparent to python or at least to have a
callback that just returns two lists (times, senders) instead of one
function call for each single spike? I guess this would be a great
performance improvement!
For now I do all of this outside of MUSIC but it would be great if you
agree on this and we can implement it at some point. Other features
requests regarding the interface could also be linked here to develop an
idea of how the interface in the next versions could look like.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#36>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADcfCRqMMVwr9QXzi7o7mXCqxA8jGPJcks5rXxgPgaJpZM4LygMf>
.
Hereby I would like to propose some minor changes to the interface;
@mdjurfeldt
Currently, there is no way to get info about the available ports in the config at an application which could be used to automatically instantiate it in a factory.
Use cases are any kind of plotting libraries/closed loop systems etc. But actually the info is available, its just accessible via an environment variable in a serialized format (a user library should not deal with that). Also info about the port type is missing. I think the port type should also be part of the config.
The second point is the Event callback for Event input ports. Would it be possible to make the buffer transparent to python or at least to have a callback that just returns two lists (times, senders) instead of one function call for each single spike? I guess this would be a great performance improvement!
For now I do all of this outside of MUSIC but it would be great if you agree on this and we can implement it at some point. Other features requests regarding the interface could also be linked here to develop an idea of how the interface in the next versions could look like.
The text was updated successfully, but these errors were encountered: