nest simulation does not receive events from a non-nest script about music HOT 9 OPEN

Dear Cristiano,

MUSIC has a flexible buffering facility. If the topology of connections between applications allows for it, it buffers spikes which are sent in a chunk.

I'm not at a keyboard now, but I suspect that what is happening here is that the sender buffers spikes and then exits before sending them.

Unfortunately, the examples that I have provided lack a statement that should always should be at the end of a Python script:

runtime.finalize ()

Try adding this and tell me what happens.

The reason why this occurs only when NEST is receiving and Python sending is that the NEST script hasn't specified limits on buffering and the Python sender doesn't call finalize () while the NEST sender does.

from music.

Thanks a lot! Unfortunately the command you propose throws the error
'pymusic.Runtime' object has no attribute 'finalize'

I saw the finalize() command in the C++ examples, but it does not appear in any pymusic example.

from music.

This should now work in current github master (commit 262f6f5).

(I have still not fixed the dist-packages/site-packages problem, so remember to move the lib/music files to the correct place after installation.)

Please let me know if this solves your problems.

from music.

from music.

You should add runtime.finalize() at the end of the script.

If you want to buffer less spikes (for example those from one tick) per communication, you can achieve this by setting maxBuffered (e.g. to 1) on either the sending or receiving port.

from music.

from music.

I debugged and found the issue! I wonder, though, if it is a bug in MUSIC or simply something I do not understand. The code above only works (i.e. the receiver actually receives spikes) if in the nest receiver I set a delay (for the Parrot neurons) and an acceptable latency (for the input MUSIC port) higher than 1.0 and with a decimal different than 0. For example: delay=0.9, no spikes; delay=1.0, no spikes; delay=1.1, spikes received; delay=1.9, spikes received; delay=2.0, no spikes; delay=2.1, spikes received, etc. Can anybody explain? Thanks a lot in advance.

from music.

Dear Cristiano,

I'm currently on vacation. Can I look at this in detail after a few days? Maybe you can send example files to my email address [email protected] and I can return to you?

A net delay around the loop which is smaller than the MUSIC tick rate is impossible. So, firstly, there needs to be a modeled delay on incoming spikes and, secondly, MUSIC should be informed that it is OK to deliver those spikes late (by as much as the delay).

What you are experiencing is probably related to the interpretation of the boundary of these conditions. To be safe, make sure that acceptable latency is larger than the minimum delay over the connection by some tiny number (eps). Also, make sure that the tick rate is sufficiently small.

from music.

from music.