Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

GR-1: only 4x8 presets?

Hello!

GR-1 is a very interesting machine, but I can't get over the fact that you can only store 32 presets on it. That is definitely far from enough on a hardware synthesizer of any format, in 2018... (Yes, this is also the reason I dislike most of things that Roland does, like how they nicely botched System-8 with just 64 patches per plug-out. Ridiculous!).

So, considering that GR-1 can only handle 32 samples up to 10 MB in size, even if those go into RAM, I see no reason why samples couldn't be referenced (instead of embedded in the preset - which is what I assume is happening here to cause this limitation in preset memory), in order to provide a much bigger storage area for presets...

Comments

  • Hello EvilDragon,

    Hm, yes, well, it could be more, but a couple of things we took into consideration:

    1) We chose to have performances (all patches + global settings) on disk. And that's virtually unlimited. You can have thousands on your USB stick. And we doubted that people play performances where they need to have a thousand patches available under a single button press .. Although in the churchorgan/cinema organ world there are performances that do require this.

    2) References are badly understood by most users. we tried this in our ST4.. using the typical tracker sequencer approach of having song positions reference patterns. Nobody under 30 years got it. Interleaving instruments on the same track? Same thing.

    3) We could have added 4 more banks. That's just 4 more buttons. But then there's the RAM issue. We could use a more flexible type of memory allocation. Or even use a new Single Board Computer.. which is probably the wisest idea anyway, seeing some people would like a true multitimbral system, and with granular polyphony this really eats CPU and memory bandwidth :D

    Anyway, thanks for the feedback!
  • anyway, that's our .. bit defensive .. story. but how about you? what purposes do you have for a large amount of directly accessible patches? could you explain? i'm not really a musician, see.. just a techy. thanks :)
  • edited November 12
    Hello!

    Thanks for the swift, and thorough reply. I wouldn't say it's defensive.

    My reasoning is not to have thousands of available patches (I understand that with RPi's 1 GB of RAM that would not be possible), but having at least more than 32 would be really great to have available in one go (then choosing them from my master controller via Program Change as I see fit). If a gig relies on a lot of granular patches, I'm pretty sure 32 would be spent very quickly, and then you'd have to go to the unit, load from USB... not something you'd want to do when you're in that sort of pinch.

    I am not sure how much the whole OS is taking up out of RPi's 1 GB of RAM, but I'd hope it'd be on the low side (Linux realtime kernel?), leaving enough to at least double from 32 to 64... Would 128 be possible, even?

    I see you have a Shift button on the device, so it seems like that could be a "simple" way of doubling the number of banks instantly available? There could also be long presses of bank buttons, to enable even more banks (provided enough RAM). Or, double-presses (say, press Bank 1 button, hold it, then press Preset 1-8 buttons, instantly 8 more banks). Again, RAM-permitting.

    Theoretically, how many banks/patches can the OS support taking current RAM usage into account (let's say all 32 samples are loaded at 10 MB per sample, so that's 320 MB already)? Or is it the case that the sample is physically loaded into every patch, even if it's the same sample - thereby occupying RAM twice if used in, say, two patches (that would seem very bad from RAM efficiency standpoint IMHO)?
  • Hi!

    The Raspberry Pi3 indeed has 1GB, but has a shared memory map. The GPU uses up 256MB, the OS uses a fair bit too (100MB..? can't recall exactly). There are some graphics buffers, then there's all the sample buffers for undo, recording and conversion. I think there's probably room for over 40 patches (with 10MB samples), actually. Maybe 50 patches.. I don't know. But 64 is probably stretching it too far. Loading a performance with 32 patches from USB stick is relatively fast. It never takes more than 10 seconds. Typically faster (but there are damn slow USB sticks everyone should avoid). But indeed, there are GUI file choosing actions involved, which quickly take more seconds than the actual loading ...

    Yes, shift button is a quite nice idea to get an alternate bank.

    The GR-1 is already compatible with better SBC's than the Raspberry Pi3. The Asus Tinkerboard has 2 GB RAM, and that would make 64 patches easily possible. Even 128 wouldn't be an issue at all. It also has a higher clock speed and bigger caches, to improve polyphony. I already hacked up the software and it runs without problems on the Tinkerboard inside the GR-1 casing :D So, is more patches would be a must for some users, there's good news. The downside is that the Tinkerboard is twice as expensive, and long term availability is uncertain (where for the Pi3 it's practically written in stone). But there are even more capable boards now, form-factor and pin compatible with the Pi3.. And there's the Pi4 next year. So, the sky is the limit.

    The GR-1's patches are folders with a WAV and a small patch file inside, which can just be written to USB stick, and in the future on network shares. It's not efficient if you're using the same sample for multiple patches, but it's easy to interchange. Actually, early version of the firmware used references to the same samples, but it was eventually dropped because of aforementioned reasons.
  • edited November 13
    Thanks for the info!

    It's really good to hear that the compatibility with better SBCs is there - but I assume stuff would still need to be done on the GR-1 OS to support those different SBCs (as you said you already hacked up :))?

    I would say that double the price is not a problem when RPi3 is $35, haha. Hardly a downside! :)

    So in case of this happening, how would this roll out? User-installable upgrade, or?


    Color me interested!
  • Aren't there 7 (?) internal Performance banks that load faster than the USB stick?
  • David, depends a bit. I think most USB sticks are on a par with the internal SD right now. Only recently have we discovered that UHS SD cards can be used on the Pi in a faster mode. We'll probably make use of this somewhere next year.

    EvilDragon, thanks! Yes, indeed there's a bit of modifying involved, but the Tinkerboard version was done in just 1 day! It's almost trivial. Others may be different.. There are hexacore little-big SBC's, which is a bit different from quad core programming. And they may have a HUGE heat sink.. And the maintenance work will increase, cos it becomes hard to test everything on every SBC.. But yeah, user-installable would be nice, yes. Could give a new boost to the project :)
  • Hey, if this actually becomes a reality, a beefed up GR-1 with more poly, multitimbral and more presets, you have a buyer right here!
Sign In or Register to comment.