While I get that new products need to be coming up in order for the company to grow, I hope this is not the case where extraverted play is prevailing. New products and technology can be exciting to hop on for sure but I feel uneasy seeing a recurring pattern of older products being put on a shelf as soon as they materialize.
I get that software updates are released once every blue moon but ffs I have been reporting issues that were never resolved or replicated and it’s been over two years.
Big update here: https://www.youtube.com/watch?v=CuMf_553Ej4
Great and bad new (for me) at the same time. I just bought the modmix from finegear… no money for the preorder, 
Pre-ordered can’t wait!
Am I right in thinking we can load up existing VSTs that we own into the DSP card? For example waves H-delay VST and run it in the box, or will it be a select number of compatible VST Fx?
No, a plugin has to be compiled for Arm Linux.
Can we run instrument / sound generation plugins to be controlled with midi? Or is it just effects?
Can midi clock be sent to effects for synchronization?
ARM Linux was a bit of a disappointment, but also makes a lot of sense.
That said, Vital has an ARM VST called Vitalium
Chris Randall of Audio Damage is interested/willing/not against porting his plugins, but not if it means buying the hardware itself. He’d need loaner/doner hardware for it to be worthwhile on his end.
There’s no chance of making it with any other more generic OS, unfortunately.
However, aarch64 is increasing in popularity and so is Linux. I just hope there are as few caveats as possible so that any potential Linux plugin can work
it will need to be compiled for ARM. That’s just the way it is, without a CPU-using converter layer, although Apple does this with Rosetta 2 (x86-64 to ARM64) so maybe it’s possible for Isla to implement something. As it’s a 1.5GHz quad core I don’t see this being too feasible.
I also don’t see Akai partnering with a competitor to sell us MPC plugins lol 
(current MPCs also run a bespoke Linux on a 1.8GHz CPU w/ 2 or 4GB of RAM).
That said, there are a lot out there. A lot of the ARM64 downloads on that repo I posted are .deb extension, though. I don’t know enough about Linux to say how Debian extensions would work with Isla’s OS.
I hope we see more in the future on how to actually interact with the card, ie, how to add plugins, etc. I can’t tell if it has HDMI out, but on the pic, the upper port has a lot of pins on it vs the ones below that I assume are probably USB. The Isla team is very, very smart so I’m sure however it is it won’t be too troublesome 
I downloaded PlugData last night, which allows people to make plugins via Puredata (free, open source Max/MSP) and export the code. I don’t know if it can export ARM64 directly, but it can do raw C/C++ code. No UI support which is perfectly fine for using with the S2400 by the looks of it.
This is the least of the issues given a toolchain is provided
Unpack and install!
And it’s the biggest hurdle without a toolchain being provided.
Windows 11 can run x64 code on ARM with an emulation layer, like Mac OS, but they still recommend a native ARM compile for best performance and battery life
So, in theory, Isla could implement something similar, which would be pretty awesome. I’ve read that debian’s multiarch can also do this sort of thing, so if Isla is basing their OS off debian it’s probably already there 
I’m sure we’ll find out more as development progresses
Without the toolchain provided you just build gcc and binutils from source. As I said, this is the least of the issues.
The translation layers are cool and all but require resources for their development. We are on copium expecting an update at least once a year with bugfixes, yet here we are discussing not only a massive new feature but another dev project on top of it.
With the S2400 being a boutique instrument, and a DSP board being an even more rare option due to the price, it is a massive undertaking for something not very feasible. However, if this is some sort of Linux with the translation layer already available, maybe we are just talking abot a package integration possibility
IIRC, the chip is Xilinx so it could be PetaLinux on there
I think I get you, now. I’m talking from the standpoint of non-open code, using any old plugin out there and you’re talking about having access to the source code. In the brief interaction I had with him, Chris Randall of Audio Damage did say it’s pretty trivial to compile his plugins for ARM.
Yes. You can still build a fine cross compiler yourself without an issue. I remember gcc-arm-eabi being broken on arch for quite a while so I had to build it myself. Sure, it took me a few hours to build it but it wasn’t difficult at all.
Although, I understand the appeal of using an existing plugin compiled for a different platform at runtime. My first thought was the possibility to run RX950, hehe 
If there’s a license involved, I doubt plugins would even work and not have licensing implications
I’m looking into PlugData right now. It’s basically PureData as a plugin and can also export plugins directly, or spit out the raw code.
I haven’t ever dabbled in the world of VSTs. Although, I have always wanted to make some AU plugin.
The reason I am talking about open-source and cross-compiling is because I am hoping Isla Instruments would make an API of everything we need to know to develop plug-ins (or integrate open-source ones) because I would probably be interested in playing with it. However, I think anything more than that might be a bit too much dev resource-intensive
Yes, I saw you mention it above! Let me know how it goes. I am a little bit interested in that, too
lol whups, I thought I did but then thought that was somewhere else. ADHD goes brrrrrrr
@cfd2 I saw on the PlugData Discord that there are PlugData builds for Raspbian. I’d have to buy a more modern Pi as the Pi 2 I have kicking around is 32-bit
I’m basically wondering if it might be easier to just develop on a native ARM system and export the plugins vs exporting raw code and cross-compiling. I’ll see what they tell me.
If you are comfortable with CLI then the remote workflow shouldn’t be difficult at all. Although, cross compiling is really not an issue and is trivial. There is a reason these tools exist and they are as easy to setup and use as a basic x86 gcc and binutils
yeah and they don’t currently support exporting to ARM on Linux anyway, it’s something they plan to add at some point.
Well, that saves me $60