#62

Has it been demonstrated on the Force? That’s extremely interesting to me…

#63

Yep (though I didn’t see the demo - this is all what Jules has told me): SOUL with the LLVM back-end generating native code on the Force. Put some SOUL source code on an SD card, plug it in and you’re away.

#64

Sounds great - I’d love to have that on my MPC Live… I was really hoping for “attach keyboard and go to a new screen” but it sounds like a good start! Was it Jules himself who’s done it?

#65

About the SOUL support on the Force. This work was done by Akai, and is using the publicly available SOUL drivers that we’ve released. It’s still an early tech demonstrator, but they are I believe looking to get this to their beta testers sometime early next year.

I believe it’ll also be available for the MPC Live…

How it works, you stick some SOUL patches on a USB stick, and insert it into the Force, then when you view plugins/inserts, you get an extra ‘SOUL Patch’ option where you can select a plugin to add. Simple as that!

They have been working on exposing their in-house GUI toolkit, which would mean it’d be possible to make a nicer GUI on top of a soulpatch.

#66

That’s awesome. Would be a really, really fantastic addition to these machines.

#67

Here’s Stephane Letz from the Faust project having a play with the Force during ADC. He chose a Faust physical model of a Clarinet, and exported that to SOUL, and got that running on the Force. It was pretty good to see, and showed the potential.

There were also some Belas running SOUL in the background, as eurorack modules.

DSCF3858 by Cesare Ferrari, on Flickr

#68

Is the source code available edit the Bela peppers?

#69

Not the source code, but the binaries for the soul command with full bela low latency support are included in the linux release - https://github.com/soul-lang/SOUL/releases/latest

When run on the bela, the I/O looks like 10 inputs and 10 outputs, with the first two being the audio i/o. Any parameters are automatically mapped to the 8 control knobs, so an existing patch with parameters gets the first 8 mapped to the knobs, and can be modulated by the 8 inputs. Patches with >8 knobs, well, you only get the first 8 to play with, sorry :frowning:

We were thinking of using the buttons on the board to switch between patches, which would be very cool, but haven’t implemented this, likewise the LEDs could indicate something like loaded patch, or level meter, but again, it’s vanilla at the mo.

1 Like
#70

the binary is just the soul executable,
so we can alter the soul patch to change parameter order etc i assume

any idea when the source code would be released?

anyway, seems like a fun way to play with soul… given Ive a couple of peppers, and salt :slight_smile:

#71

I’m a little confused about what is actually released under which licenses. I understand there’s both a SOUL language and a runtime… or several runtimes?

A very important question for me is, is it possible to compile SOUL (to anything - an IR or C++) using only tools with sources available under free licenses, or do I need to get the binary release? And if I do, will that change?

1 Like
#72

To answer your question about the licenses is a little involved.

The whole system is comprised of a front end language (SOUL), an intermediate representation (Heart) and a runtime to JIT the code (no clever name for this, we call it a SOUL runtime). The runtime takes in Heart, not SOUL, and JITs this, or, we can convert this to C++ as well for integration into more conventional projects.

As of now, the open source bit is the parser and compiler which converts SOUL into Heart, so basically the language definitions are open source as well. We haven’t opened up the runtime, and this is for a number of reasons, from boring things like we’re not sure if we’re going to license this code to device manufacturers or open it, through other things like there’s lots of churn in that part of the code, and we’re still working through what we want the interfaces to look like.

I’m guessing from your comment that you don’t want to commit to something which requires closed source components, and I totally understand that. We might see some movement in this direction soon, with either this implementation being opened up, or a reference implementation being released.

Meanwhile, the closed source binaries have been released with very permissive licenses - you can use them for fun or in commercial products.

1 Like
#73

No idea on the source code - certainly i think for something like Bela it might be useful as you’ll probably want to enhance it in interesting ways to work well with the devices UI.

Well do have a play with the Belas, i’m a big fan. They aren’t hugely powerful, but they seem to be very robust and easy to work with.

Similar to the Bela, i’ve just received an Elk OS board, so that’s my Christmas sorted!

#74

Yeah, it’d feel really weird to me to write in a language where someone else could take the compiler away. I used to be well into Reaktor before I moved to Linux for my main desktop and that was a lot of work I had to walk away from, and even if I got a new Mac I’d have to upgrade. I’d rather not be in a situation like that again.

I can accept that you want to keep some parts closed for easier monetization (and as a dev myself I’m also intimately familiar with “good enough for production but not good enough for Github”!), but I’d be much more comfortable using SOUL if I knew I would always have the infrastructure to e.g. compile it into Faust or C++, even if I would predominantly use it on a proprietary runtime (Akai) for the moment.

2 Likes
#75

exactly the reasons id like to see this open sourced …so that the community can extend, and take to new platforms that might not interest Roli.

as a developer, Im with @rvense - if im investing time into something new like SOUL, Id like to know I can move it to new platforms if needed, or add features that I require.
Pepper is a good example here… we now have to wait for Roli to extend to support the LEDs, buttons or things like I2C.

of course short term its not an issue
I completely understand the need for things to mature before being opened up… i’d do the same. Also i respect that it make take a little time for Roli to determine how they monetise this, to help pay for its development and support.

anyway, its great to see SOUL progressing, and getting nearer to a release.

2 Likes
#76

The problem is that you are seeing this as a proprietary programming language, and whilst that’s the case, worrying about the implementation being closed is a valid issue.

If, say, there was an agreed ISO standard for SOUL, and the major phone/console manufacturers provided built-in support for it, and it became a de-facto ‘check list’ item for things that support audio, you’d I imagine have no such concerns, even though the implementations were still closed source. Basically, a single supplier is the issue, not the closed nature of the implementation.

Looking at, say, the graphics world, the fact that Nvidia and AMD keep their graphics hardware drivers closed source doesn’t mean people shy away from using Vulkan, as the choice of vendor for end users keeps them honest.

If we look at SOUL through the same lens, the right strategy very much depends on whether we’re seeing this being adopted and available in major OSes, or whether we see it as one companies interesting tech. I’m shooting for the major OSes supporting it, but it’s not going to happen overnight as you can imagine. You’ve got to think big though, haven’t you?

#77

An ISO standard would also require that the language is not owned / maintained by one company.

But as you say it’s a growth thing , it needs to grow beyond one implementation, one company - that can only happen by adoption by developers, manufactures - chicken n’ egg.

I’d guess, these days, you’d need at least a decent open source reference implementation for developers etc to cast aside the doubts of it being proprietary…

But all early days , first stop is determining it solves a problem without introducing others :wink:

1 Like
#78

Just a quick FYI for anyone who was following this thread that Ces and I recorded a tutorial with Joshua Hodge of theaudioprogrammer.com which might be of interest:

:slight_smile:

4 Likes