undefined | Better HN

0 pointsPaulHoule4y ago0 comments

When you can’t take no for an answer in software development you often have to get some hardware.

In your case a Windows machine or maybe you boot your old laptop into Windows. People report that older Windows drivers work perfectly in Win 10 but don’t say that in the .ini file. A 1 line change fixes that.

Maybe you can do the same with macOS, but the platform is less open.

What I call virtualization could be many things like tunneling the usb packets into VMware, but could also include binary patching the driver, or running the driver inside a simple emulator (only has to support the exact features the driver needs and the driver probably doesn’t do very much so throughput is a non-problem)

For instance you could use Libusb and pyusb and run the driver inside an interpretive emulator inside Python, observe what it does and replace one bit of functionality at a time until you know how it works.

Latency is tougher than throughput.

M1 runs ARM, I know it uses a binary translation emulator to run x86, how much backwards compatibility it provides I don’t know. If Apple were motivated to keep old drivers working they could do better than they do.

What I see is contradictory but some reports indicate it can use the standard audio drivers to run at 16 bit resolution and 44.1/48 sample rates. 24 gives headroom and high sample rates are great for effects processing, but you might be happy with the results you get with the standard driver if that’s the case.

All of these, for an individual, would cost more than a new USB audio device from a vendor with a different attitude. Roland’s attitude is a bad one for a vendor for tools for pros and other serious users; you can justify a high purchase price for a product with a long lifetime.

Searching I find there is a huge amount of frustration and you might do a Kickstarter.

0 comments

mortirolo4y ago

Hi again. Thanks for your reply and explaining a little more about ideas for virtualisation. I am quickly getting out of my depth but at least now have an idea of possible directions to research and learn.

I also read the 1 line change fix for the Windows driver in a forum. Infuriating. It seems a stone cold profit / loss decision to brick the device when it would have been so easy to ship an updated driver.

But I also think that it shows a lack of imagination: if it's just about profit, Roland should let their customers pay for new drivers. Drivers can be an income stream, too, and after so many years of use, paying for an upgraded driver is not an unreasonable request.

Unfortunately at the time I bought this device, I was not wise enough to save and buy a device by a more conscientious company like RME.

I have contacted one of the more experienced developers at Roland to see if they might be willing to unofficially guide an effort to update the driver. That would definitely streamline the process.

Thanks also for the point about class-compliant mode at 16/44k. It is a good point and would give use of the analogue limiter. Although I am really trying to work with higher resolutions and not having use of the midi port is also a bit of a pain.

I agree the idea of a kickstarter for this device is worth testing.

Taking a step back, I also wonder whether a group of developers specialising in coding drivers for a whole range of unsupported audio interfaces could make decent money from grateful producers via patreon / kickstarter. That is if they weren't flooded with cease and desist orders.

j / k navigate · click thread line to collapse