Hi guys,
i´m porting some VL system from Beta 37 to Alpha 38.2 Build: 22 04 2019 14:26:58
The system consist in 3 devices connected, sending and receiving Midi, and a Skia UI.
The beta 37 version works fine, and reconnect midi devices is fast and not invasive.
In the Alpha seems reconnect midi devices does not work as in Beta 37, it takes much longer and sometimes it does not recognise new devices or disconnect some of the already connected.
Also FPS goes down a couple of times until the background operations finish (i don´t know exactly what).
Did you change something on this side since Beta 37?
did you test it with a simple patch with only one MidiIn node and reconnect? do you see all devices then?
yes, two things, we fixed a bug when you have multiple devices with the same name, they now get a #2, #3 etc. attached to their name. also an update of the enum triggers a compilation of the patch in order to update error messages.
Hi Tonfilm,
i get the same results using just the Midi In / Midi Out modules, High CPU overhead when i reconnect devices.
Other think to keep in mind, i´m using SetProcessAffinityMask to constrain the MIDI instance to 3 Cores,
In Beta 37 using ProccesAffinityMask does not affect visibly the FPS.
In Alpha 38.2 the FPS drop down is higher when i use less cores, but the problem remains, even using all cores i experience a High CPU load and the correspondent FPS drop.
Here the Midi In Module i´m using, Midi Out works in the same way.
i set automatically the device using ListInputDevices and FindDeviceWithName, maybe they are doing something in the background, but i don´t see any performance change on those modules when i reconnect devices.
do you have the same spike when you move a inlet/outlet in the patch? as i said above, midi device changes will now trigger a patch re-compile. the same as if you would change that patch.
also this part should probably not be running on update in every frame, it’s not a cheap thing to do… why don’t you want to use only the dynamic enum IOBox below it?
Ok,
i’ve investigated a bit, and also without ListInputDevices and FindDeviceWithName logic, i get high CPU peaks, basically the same behaviour, and other problems, red Enums when the device is not found and unresponsive VL editor.
One of the good things in VL was Painless Midi devices re-connection… until now.
that’s probably the recompile. how problematic is that for your work? i hope you don’t have to plug and unplug the devices every minute.
what described above with multiple devices? so you are saying only two of 3 devices get detected, is that correct? which midi controllers are they?
i’d say that’s a feature! if a device is not found, the system should inform you about that. the recompile is necessary because otherwise the error would not go away if you connect the device and the patch is not open. see here: Dynamic Enum bugs
you can still avoid red IOBoxes by looking for the midi device on your own with the patch you posted. you can use the HardwareChanged observable for that.
i’d say it’s the same as before, only with velcromes bug fixed. there was no other rework or anything…
Hi again,
You should know if something is going to fail, it’ll happen in the climax.
The ideal situation is not to unplug the midi devices when the show is running, but in my current setup i get midi clock from stage, and this is an uncontrolable thing.
My midi controllers are, Icon Platform m+, Launchpad mini, Launchpad Pro,
Using Alpha 38.2 in my current setup, i get all of them running only at fresh start. If i reconnect one of them, no more than 2 devices show connected, and sometimes the midi out on some devices shows connected but not responsive.
I think i can address this problem in a non elegant way, simply running the midi modules in other instance, but my idea is to make a stand alone version in gamma, and the new midi behaviour makes it unusable.
Currently there is not a way to avoid CPU peaks when reconnect midi devices, and it makes very difficult to have a smooth animation running (or a preset engine in my case) and the midi modules in the same instance.
maybe the recompile method is not the optimal solution?
How can i help you to fix it?
The way I understood this is that a manual Recompile is just a temporary measure until devvvvs find time to actually fix the dynamic enums to be dynamic. hence there is no post marked as a solution to this thread.
However, now I just saw that that thread got sneakily tagged as fixed-for-alpha, where you seemingly took care of just one bad side effect of your proposed workaround, instead of actually fixing the enum.
not sure if i understand, from your text it seems that you have more than one issue? i thought it was about updating/removing the error even if the patch is not open.
i thought about it and currently missing dynamic enum entries are compile time errors. maybe they should be run time errors. or even a new category of errors that can be managed by the user. when you export an executable this also has to be taken into account somehow… so the behavior for that case also has to be specified.
this sounds like a bug, i see if i can reproduce it at home with my controllers. if not, it would be helpful if you could bring all of your devices to our office to debug it properly.
i think i got the whole picture now and will see what can be done to improve the experience. thanks a lot for the detailed report.
the reason for devices not showing up sometimes, seems to be the usb device installer. upcoming versions now wait for any device installer to finish before enumerating the driver list.
the other issue of a re-compile on device change needs some more changes. this is about error message handling. if a device is not found, it should probably result in a runtime error (pink) instead of a compile error (red). for this to work properly so that the rest of the patch still runs, a bit more work is required. we’ll update this thread once we have news on the issue.
