Start a new topic

RSP standalone loads default presets onto Seaboard and Lightpad Blocks - with ugly consequences

Windows 10 1903:


When RSP v. 0.3.0 is started and in focus it will load the stock "Note Grid" program with  some default settings onto all Lightpads it can detect. There seems to be no way in RSP to exclude some Blocks from detection and being switched to default "Note Grid".


This is not good behavior, because

a) it can sometimes take quite a while until the Blocks are properly loaded

b)  the user may want to use some Lightpads to control other stuff even when RSP is running as Standalone in the foreground and thus wants entirely different apps loaded

c) the user may prefer to use other versions of Note Grid (for instance I use a tweaked one with individual colors for each note in a scale, like 4th are red, 5th are green etc), or completely different programs

d) (and this is most important, even a showstopper!)

If the user has more than one Lightpad  next to each other, then Note Grid default means that both Lightpad send on channels 2 to 16 and don't care if the neighbour Lightpad already uses a channel, which leads to channel sharing problems as described in the thread Proper polyphony for multiple seaboard blocks.


The recommended solution for the channel sharing issue on Lightpads and Seaboards is to go in and assign an individual channel range for each involved device. Reloading the program that runs on the Blocks means all the users changes are discarded and the battle of the notes begins.


Here's a screen capture of two notes battling over control In the "Assign... "window you can see what I am doing and below in RSP's UI keyboard is visible what is made out of it:

image


You also see a time counter in the bottom right. The missing  seconds (1 through 19) is me waiting for Lightpads to load the note grid program I didn't even want loaded. It's not always taking that long, but sometimes it feels even longer.




What's more:

RSP even seems to also overwrite the settings of my Seaboard Blocks with settings that don't care for the channel issue. So with Seaboard Blocks the very same thing happens as with Lightpads. Why does RSP even meddle with Seaboard settings, other than octave range?

In effect, this behavior renders using multiple Seaboard Blocks incompatible with RSP standalone.


This is a showstopper issue and needs to be fixed urgently !

First RSP should have an option to not overwrite the programs on my Blocks until the user assigns and enables a hardware control of one of RSP's sections. This seems to work flawlessly with RSP as a Vstplugin.


Second, the channel issue has been annoying users a long enough time now and was promised a fix ("in a future version", blabla) many month ago.


Please get your stuff together and start fixing things. I've got lots of unresolved tickets in the support tracker, all confirmed and all put off to that fabulous "future version" most since February last year. 


Hi Frank, thank you so much for this detailed report of the issues you've encountered. Firstly, we're pleased to say that we've made significant progress on resolving the channel sharing issue, which we appreciate has caused an inconvenience for longer than we had hoped and has required significant development time to resolve and improve. However, we're more hopeful than ever that an update will see the light of day very soon, so this will remove the requirement of any current workarounds that are then broken by the current ROLI Studio Player functionality.


Currently the hardware integration within ROLI Studio Player cannot be split across "some" devices - control is either over all connected devices or none at all, which can be toggled by clicking the power icon next to "Hardware Control" at the top of the RSP window. You should find that any apps that were previously loaded on to you Lightpad Blocks should be retained, but as per the current behaviour, enabling Hardware Control will then update the Lightpad Blocks to make them available for assignment within RSP.

You feedback is very valuable and we'll look into ways to improve the hardware integration to allow more detailed, customised control over exactly which devices in your setup are used to control RSP. I'll log this report with the development team and we'll look to improve the functionality in a future update to ROLI Studio Player.


In the meantime, if you encounter any other issues with this version of ROLI Studio Player, please don't hesitate to let us know.

Thanks for the detailled response :) You can now disregard the question in my Hardware Driver issue thread about this thread not appearing.


I am very much looking forward to the update with a fix for the channel problem. Here's hoping that at least some of the other issues I and others have raised with Dashboard will be resolved too.


Thanks also for mentioning that with Hardware Control disabled the original apps are available, that helps a lot!

Still I hope you'll find a way to enable Hardware Control for specific devices, that'd be very useful. As said, this doesn't seem to be a problem in the plugin version (although I can't faithfully test it, because of that other issue I have with Hardware Control Driver acting up on me and my DAW being a pita to use on the Surface where the driver works as intended).


What's still puzzling me is why Seaboard Blocks are affected by this issue, too? But as soon as the channel issue is fixed that will pose no problem anymore and is maybe useful for future plans regarding the control of Seaboard parameters from within Connect and/or RSP.



Once the channel issue is resolved, the only significant problem left from this report is the time ist sometimes takes to load the apps on Lightpads. I just took some tests on the Surface tablet and found that the time increases a lot with the amount of Lightpads connected:


One Lightpad: ca 5 secs

Two Lightpads: ca 15 secs

Three Lightpads: ca 25 secs

Four Lightpads: ca 35 secs


These numbers seem to vary up and down a couple of secs with each attempt and my approach to take them is certainly not scientific, but that's about the repeatable ballparks.

Meanwile, when I disable Hardware Control, the original apps are available pretty much instantly.


For these tests I had all involved Lightpads connected via DNS to a single Seaboard all connected via a single USB cable to the Surface. A quick test with an added second Seaboard yielded about the same results.

 Seaboard Blocks seem to change their setup pretty much instantly, or at least they are playable without much of a pause.


If these figures can't be significantly lowered, that's one more reason to not involve all connected Lightpads to the loading spree.

Hi Frank, we'll certainly look into more flexibility with regards to hardware integration.

We haven't performance any testing in-house on Surface devices, but have not received a significant number of reports from Surface users. Do you experience the same delay in connecting when using ROLI Dashboard, or is this an issue that only manifests itself within ROLI Studio Player? We'll perform further in-house testing to attempt to reproduce delays as long as those you've reported, and hope to determine the cause of the delay.

The load times are not Surface related. If anything, the common factor is Windows 10. I can attest that I experience very similar figures on my desktop computer.

But as I have to use a workaround on that computer, starting ROLI Hardware Driver in a way not intended by you (explained in another issue report thread), I wanted to rule out false figures.


For this test I just hook the devices up and disable and re-enable "Hardware Control" within RSP. Disabling is fast, enabling exposes the reported delays. I think (hope, sort of) this should be easily reproducable. At least the tendency, not necessarily the exact figures. 

The Surface is running Win 10 pro v.1809, the main computer is Win 10 Home v.1903.


When I use Dashboard, the wait time is mostly in the short range, maybe because Dashboard concentrates on a single device at a time? I have experieced longer load times on occasion, but not as a rule.

Just tested:

IOS Noise is loading its app into four Lightpads very fast. No detectable difference to loading a single Lightpad. Same setup (1 Seaboard with 4 Lightpads attached to it), but using Bluetooth. That makes me hope there can be a solution for Windows as well, at least it doesn't seem to be a restriction from Lightpad's side :)

Login to post a comment