Seneral

Fair enough, the current solution is a bandaid on a bigger problem, the fact that the WinUSB backend has an additional parameter (ContinueStream) that is very important for it's behaviour...

Good to hear, though the WinUSB implementation with the behaviour of ContinueStream is suboptimal anyway and there's nothing we can do about it - If anything interrupts a isochronous stream...

Yeah I figured as much, though you could switch to libusb on linux which has proper isochronous support. As for WinUSB isochronous transfers, as far as I understood back then...

I will create three separate PR requests, unfortunately right now I don't have time. The first two simple fixes are correct, the third workaround works but is not pretty. A...

Ok thanks! I do have interrupt working on the alt_0 interface, however I'm currently stuck with a FS USB device (STMF103) with a maximum interrupt size of 64, which is...

Found one issue in the current repository state, [This line ](https://github.com/libusb/libusb/blob/master/libusb/os/windows_winusb.c#L1776) passes SUB_API_NOTSET to the copy_transfer_data implementation, and this seems to have been the case for at least the past...

So it turned out changing [this line](https://github.com/libusb/libusb/blob/master/libusb/os/windows_winusb.c#L2642) as I intended did the job and most everything worked as expected. However the occasional error even in the (8,8,8) setup remained and...

Alright, created a PR. Here's some example code that I quickly adapted from my code. Makes use of these changes to create a pretty solid isochronous stream. ```C++ #define USE_WINUSB_BACKEND...

What do you mean data lost? Could you elaborate? The canvas should be preserved, even if you do not explicitly save it. If it does not, it is either a...

So to clarify: 1. You did not save the canvas in the scene explicitly, you just had the scene open while editing, before saving it as an asset 2. The...