micpool's picture

@micpool

Groups

    micpool's picture

    Receive MIDI events node crash with Sysex overload

    micpool's picture

    Status: 

    Vuo version: 

    Fixed in Vuo version: 

    OS version: 

    • OS X 10.10

    How severely does this bug affect you?: 

    ●●●○ — It prevents me from completing a specific task with Vuo.

    Steps causing the bug to occur: 

    1. Connect a MIDI input to the MAC that has a lot of MIDI sysex. In my case I am using a Roland Octacapture which communicates with its Mac editor through Sysex on a MIDI port named MIDI CNTRL It sends packets of 29 bytes of sysex repeatedly when the editor is open. This port appears in the MIDI input list in Vuo.

    Have you found a workaround?: 

    Not selecting that interface. However this is quite difficult to do, as the only way I have found of selecting on screen which interface to use is by stepping through the interfaces, either with a slider or dec/inc buttons.

    Other notes: 

    I think this will be a problem with any MIDI device which sends lots of sysex data as part of its MIDI spec.

    Screenshots: 

    Compositions: 

    AttachmentSize
    Binary Data Receive MIDI events Bug.vuo1.3 KB

    Crash reports: 

    micpool's picture
    micpool posted a new Discussion, “Selecting MIDI input

    Selecting MIDI input

    micpool's picture

    All your MIDI input examples just show using the first device. Whilst selecting the MIDI device is easy in the editor, what would be the best way of a user selecting a device when the composition is compiled as an app?

    Sometimes it is useful just to specify a channel number, and have any incoming MIDI on that channel recognised. Is there any way to set theMIDI device to all instead of first available, or a specific device?

    Thanks

    Mic

    micpool's picture
    micpool commented on micpool's Discussion, “Process one list with another

    Having said I couldn't break michele's solution, I now find I can. The first version of my app output whole second timers only and so I was running the fire periodically node at 2 events per second. I had tested this version on a 2008 MacBook Pro running 10.11, a 2012 MacBook Pro running 10.10, and a 2018 Mac Mini running El Capitan. I then added the ability to display 1/10 seconds so had to increase the fire periodically node to 20 events per second (0.05). I tested this on the 2008 MacBook and it ran fine.

    However when I tested it on the 2018 Catalina Machine the fire periodically node was dropping events like crazy which meant that Michelle's solution which requires precise synchronisation of data through a chain of update and clear nodes went completely haywire. I don't know if this is a Vuo thing or a Catalina thing and don't have the time or the inclination investigate further. However I wanted to tidy up the app so it would at least run on that machine, just not updating the time (effectively the 1/10 seconds) on the dropped frames.

    I decided to look agin at Bodysoulspirit's matrix multiplication solution again , and managed to get it to work. It would appear that the 'Get Items from List'Node is behaving differently when presented with an explicit empty list, or a list of integers which changes to an empty list. although I don't understand the difference.

    This works because it checks to see of the list produced by the reverse node is populated and if it isn't sends an explicit empty list of integers. It doesn't make any sense to me, that this should work but the original didn't but I have filed it as a bug report to see if this is intended.

    Thanks both for your help again,

    Mic

    micpool's picture
    micpool commented on micpool's Bug Report, “Bug in Get Items from List mode

    I have now reduced this problem to a very simple composition (attached)

    It would appear that the 'Get Items from List'Node is behaving differently when presented with an explicit empty list, or a list of integers which changes to an empty list. although I don't understand the difference.

    In the example workspace the top example works because it checks to see of the list produced by the reverse node is populated and if it isn't sends an explicit empty list of integers. This works

    The lower example just accepts that the output of the reverse list is empty when it says it is. This produces the wrong output from the Get Item node.

    I hope this makes the problem clear

    Thanks

    Mic

    micpool's picture

    I'll try and catch the logs if it happens again. My bug report wan't about the specific crashes though. It was that if you force quit Vuo then the Vuo composition loader remains active (and if there is no output window it is completely hidden ) until the computer is restarted or until it is terminated in activity monitor.

    Because this is attached to the OSC port on localhost e.g.127.0.0.1:53001 when the composition is reopened in Vuo a new composition loader is started when it is run (also hidden), but this new composition loader cannot connect to the port because it in use in the ghost Composition Loader.

    Simple composition attached

    1. Load composition and run
    2. Monitor OSC received
    3. Force Quit composition
    4. Because Composition does not have an output window the composition loader, which is still running, and will prevent the composition from receiving OSC next time it is run, is hidden and can't be quit without accessing the activity monitor..

    Pages