A couple of questions, grain synthesis and UNIT development

[Rick Burnett]

Transferring my question over here instead of Muffwiggler! :) First and foremost, great work. I received mine and am having a blast with it. I've been wanting a sampler in my rack for awhile and have not been happy with the 5 or more other options I tried before the ER-301   Question Time!   1) I saw that you are going to compile a list of feature updates coming along. Just wanted to ask about a grain oscillator, is that coming as well? That's one feature that I plan to get a lot of use out of!   2) API wise, pertaining to the C++11 code, how much are we going to have access to using? For instance, can we take advantage of the Neon core in the cpu? Are you going to have a cross compiler toolchain people can download? Will we be able to include custom libs as well, or are we going to be statically linking everything in?  3) Have you thought of a patch or unit sharing system like max4live.com where we can share these things with each other?  Again, thanks for making this!

[Brian@O|D]

Hi Rick.  Thanks for joining here.

1)  Yes!  Granular is coming in various forms.

2)  Still working out the details but I want to avoid static linking of user code.  If dynamic linking turns out to be a hassle I will probably go with jump tables.  You will have access to the Neon core.  The toolchain is from TI's PROCESSOR-SDK-RTOS-AM335X which uses gcc-arm-none-eabi:

http://www.ti.com/tool/Processor-SDK-AM335X

The general architecture is that low-level modular DSP blocks and GUI widgets are written in C++/intrinsics/assembly and glue code is in Lua.

3)  I have thought about this but at the moment due to firmware volatility there is a high risk of patch obsolescence which would confuse and hinder any large-scale patch sharing. I'd say this comes after the plugin framework goes live.  Peer-to-peer patch sharing (say for example on this forum) is encouraged however.

[Rick Burnett]

1) Excellent!  Looking forward to playing with the granular stuff!  

2)  That makes sense about the firmware volatility, once you get that locked down after all the decisions have been made and we are out of the bleeding edge phase!

One thing you might consider is firmware stamping early on in terms of what version of the OS a plugin is written for.  Right now where you are going to have a lot of flux, that doesn't make sense, but long term, when things slow down from the firmware level, if you will, that could be an option.  This would let people know what the compatibility expectation is as well.  Might be as easy as just a define that comes out of your headers per dev kit release, or however you manage the API per OS version.  I'm using a similar mechanisms for patch data storage on GateStorm for preset repair as I add more capabilities to it.

And gcc-arm-none-eabi is what I use ALL the time :) So that sounds great.

[Brian@O|D]

I very much agree on the stamping.  From the beginning all preset files have had the firmware version descriptor included.

[Kevin Halloran]

Rick, if you program and share stuff that would be super cool. my gatestorm and er-301 are good buddies!

[Rick Burnett]

I will definitely be writing some code and sharing! :)  I will be doing a lot with er-301, radar, and gatestorm over the next few months! 

[John Wise]

Make me buy a Radar, just show me it at work doing magic with the ER-301 and I'll step right up.

[Rick Burnett]

Haha!  Well it's coming.  Expect some ER-301 and RADAR demos soon, probably after the granular stuff drops.  That's an area I really want to experiment with.