#83

Yes I did but in this case i’m considering bela only to play 12 channels of audio in the context of an installation, with no eurorack or stuff of any sort except loudspeakers.

1 Like
#84

Generally, their starter kit , means they include the Beaglebone Black and 2 I/O cables (one for input, one for output )

looks like its the same for the beast…
I think the reasoning is… most have an sdcard, and the IO cables suitability depends on your project, as they are ‘reasonably’ short, so for some projects its better to make up your own cables.

thats what ive seen with my Bela starter kits, its possibly different with the Beast, but given the options, that looks like what they are doing - but check with Guilo, it may be different.

note: the bela cape is not required/included for the beast… you’d only get if you wanted 2 more IO, but mainly for the analog input and output.

#85

so my belamini turned up about a week back, but only finally got around to playing with it…

and wow, its small, just the size I need to fit into my AE modular :slight_smile:

IMG_2277
IMG_2277.jpg1024×768 297 KB

as the AEM is 5v, belamini can be powered directly, and its 8 analog inputs can be fed directly too.
so here Ive got a test patch which is having its frequency driven from an AEM LFO…
this was just a test to see if there was any switching noise, (which there wasn’t - yeh!).

next need to do a small protoboard, and drill out a spare panel, its a tight squeeze (5-7mm) , but think it’ll work.
I then want to convert audio i/o to AEMs 5v DC , and possibly level convert a couple of digital inputs (3.3v) for trigs/gates.
(also need to see if i need to protect the analog ins against being connected to other inputs?)

but overall very simple to do… and provides a whole bunch of possibilities.
(and love AEM is inexpensive too, so if i blow something up, not the end of the world :slight_smile: )

6 Likes
#86

How is the quality of the audio out on the Bela?

1 Like
#87

@philmaguire , generally or specifically? generally its very good… proper codec, low latency, whats not to like :slight_smile:

ok, so I ‘finished’ the AE module : Bela AE Module (needs a better name!)

some ‘specs’

  • 8 CV input
  • 2 audio/cv outputs
  • based on Bela Mini, so A8 1ghz, low latency
  • fits in AE Module , 2U module (5x10x3cm!)

(Im thinking of perhaps building an expander module, more digital io, perhaps audio i/o(3.5mm jack) and leds, perhaps even controls :slight_smile: )

IMG_2281
IMG_2281.JPG640×853 218 KB

mandatory first signs of life bleep and bloops (with dodgy phone audio :wink: )

I guess, I’ll do a proper video and put on my youtube channel once I pack away all my tools :slight_smile:

First time Ive every created a module, and was quite a lot of fun…
(though wow was it a tight fit… especially for my limited skills, and doing on protoboards)
might be tempted to create some other modules :slight_smile:

(not sure how Im going to find time, so many software projects on the go, let alone adding more hardware ones!)

3 Likes
#88

Bela looks really interesting! I was lucky enough to be one of the artists chosen to be part of the Queen Mary University ‘D-Box’ project from which Bela later developed, got some pretty hectic sounds out of it :slight_smile:

1 Like
#89

this brings it into “serious project” status for me…also shows how incredible Norns is and how reasonable cost wise

#90

i know the bela forum is definitely the better place for this, but since i just created my account there, my post has been in “waiting for approval” limbo for over a day now, so i’m hoping maybe someone here can help me figure out what’s wrong with my code??

i’m working on my C / C++ chops, and trying to wrap my head around libsndfile. the intention is to generate a sine tone for an amount of time (like 5 seconds or so), and write it to a wav file. my code so far is sort of a combination of their basic sinetone example, and an adaption of their sample-streamer example with a write function, rather than reading in a pre-recorded file. the gist is that it alternates between an active buffer filling in the sine values in real time / audio rate, and a non active buffer that writes the previously recorded buffer into the file via a lower priority thread.

the issue is that my resulting file is mostly silence, except for the last half second which is the recorded sine. (the 2 buffers i’m creating are both 22050 samples long, so it’s correct. if i change these two buffers to be 44100, the end would be 1 second, etc)

45%20PM
Screen Shot 2018-11-13 at 4.01.45 PM.png702×246 9.39 KB

i’ve looked through my code multiple times but just don’t have any more ideas at this point. i’m sure it’s some small silly mistake or misunderstanding of libsndfile on my part. any input would be appreciated :slight_smile:

here's my code 
#include <Bela.h>
#include <cmath>
#include <SampleData.h>
#include <sndfile.h>				
#include <cstdlib>

#define NUM_CHANNELS 1    
#define BUFFER_LEN 22050   

float gFrequency = 440.0;
float gPhase;
float gInverseSampleRate;

float gDuration = 5 * 44100;
float gCount = 0;

SampleData gSampleBuf[2][NUM_CHANNELS];

int gPos = 0;
int gActiveBuffer = 0;
int gDoneLoadingBuffer = 1;
int gChunk = 0;

AuxiliaryTask gFillBufferTask;

void writeFile(float *buf, int startSamp, int endSamp){
    SF_INFO sfinfo ;
    sfinfo.channels = NUM_CHANNELS;
    sfinfo.samplerate = 44100;
    sfinfo.format = SF_FORMAT_WAV | SF_FORMAT_PCM_16;

    const char* path = "./test.wav";

    int frameLen = endSamp - startSamp;

    SNDFILE * outfile = sf_open(path, SFM_WRITE, &sfinfo);

    sf_seek(outfile, startSamp, SEEK_SET);

    sf_count_t count = sf_write_float(outfile, &buf[0], frameLen);

    sf_write_sync(outfile);
    sf_close(outfile);
}

void fillBuffer(void*) {

    gChunk += BUFFER_LEN;
    int end = gChunk + BUFFER_LEN;

    writeFile(gSampleBuf[!gActiveBuffer][0].samples, gChunk, end);

    gDoneLoadingBuffer = 1;
}

bool setup(BelaContext *context, void *userData) {
    gInverseSampleRate = 1.0 / context->audioSampleRate;
    gPhase = 0.0;

    if((gFillBufferTask = Bela_createAuxiliaryTask(&fillBuffer, 90, "fill-buffer")) == 0) {
        return false;
    }

    for(int ch=0;ch<NUM_CHANNELS;ch++) {
        for(int i=0;i<2;i++) {
            gSampleBuf[i][ch].sampleLen = BUFFER_LEN;
            gSampleBuf[i][ch].samples = new float[BUFFER_LEN];
        }
    }

    return true;
}

void render(BelaContext *context, void *userData) {
    for(unsigned int n = 0; n < context->audioFrames; n++) {

		float out = 0.8f * sinf(gPhase);
		gPhase += 2.0f * (float)M_PI * gFrequency * gInverseSampleRate;
		if(gPhase > M_PI) {
			gPhase -= 2.0f * (float)M_PI;
        }

        if(gPos == 0) {
            if(!gDoneLoadingBuffer && gCount <= gDuration) {
                printf("increase buffer size!\n");
            }
            gDoneLoadingBuffer = 0;
            gActiveBuffer = !gActiveBuffer;
            if (gCount <= gDuration) {
                Bela_scheduleAuxiliaryTask(gFillBufferTask);
            }
        }

        if (gCount > gDuration) {
            for(unsigned int channel = 0; channel < context->audioOutChannels; channel++) {
                audioWrite(context, n, channel, 0);
            }
        } else {
            gSampleBuf[gActiveBuffer][0].samples[gPos] = out;
            for(unsigned int channel = 0; channel < context->audioOutChannels; channel++) {
                audioWrite(context, n, channel, out);
            }
        }

        gCount++;
        gPos = (gPos + 1)%BUFFER_LEN;
    }
}

void cleanup(BelaContext *context, void *userData) {
    for(int ch=0;ch<NUM_CHANNELS;ch++) {
        for(int i=0;i<2;i++) {
            delete[] gSampleBuf[i][ch].samples;
        }
    }
}
#91

two bits of bela ‘eurorack’ news from Superbooth that dont seem widely reported…

a) Bela Salt
new batch being made , available for pre-order
(Ive had one for a year and love it, I’ve used it in so many different ways this year)

b) Bela Pepper
a cheaper, DIY alternative to Bela Salt.
its ‘passive’ so doesn’t have the same voltage ranges as Salt, and it doesn’t expose the USB ports (*),
but the PCB is 20GBP, and components I guess around the same - so probably going to come in around ~ 50 GBP? which good value to me.
(Im getting one to accompany my Salt )

so (~) < 200GBP (beaglebone + bela + diy) for a fully programmable eurorack module with 8cv in , 8 cv out, and 2 audio in and out !

hopefully by making it more ‘accessible’, it’ll be more enticing to developers :slight_smile:

(*) you could of course do this yourself with a usb extender.

more details here

9 Likes
#92

I’m wondering if anyone on this forum is actively working and developing on the Bela platform? For a little while now I was contemplating to get back into a norns, but I still have a Bela from the original batch kicking around that I never did much with. So I’ve decided that this will be the platform to learn a tiny bit of coding.

I’d love to focus on migrating existing patches from PD or CS (or norns?) to Bela, so any pointers and examples on how to go about this would be much appreciated.

#93

yeah, I’ve done quite a bit with Bela (in its various guises) - its a great platform :slight_smile:

for both CS and PD, patches generally work pretty much ‘out of the box’ , in particular audio ‘just works’
the main effort is adding digital and analog IO, which there are examples for.

if you’re converting PD patches that are not vanilla PD, you’ll likely have to compile some externals, that’s not that hard… and some threads on the Bela forum about it.
also I think quite a few externals have already been compiled, and many are already compiled for arm and available from deken that will just ‘work’
(e.g. when I did orac, the only external I had issues with was the ableton link, but thats was easily resolved)

CSound, I used a while back, and it was very straightforward, but i did have a few issues - however, I believe these have now been fixed.

Supercollider,
you mention porting from Norns - so norns is Lua + Supercollider.
Lua i guess could be run on Bela but most of the Lua code in Norns is UI code, which is ‘inappropriate’ for Bela (no encoders/display) - and the supercollider code is quite tightly coupled to this lua interface (as norns has an api based around parameters/pollin)
so really, I don’t think there is much to use from Norns, without re-write a very large percentage of it.

However, id not let that put you off Supercollider on Bela
Ive had a lot of fun with supercollider on bela, by using plain ol’ SClang - in particular I love all the pattern def stuff, and doing live coding on it.
Like PD and CS, the integration of the bela IO is also really good and easy to use.
(again, I did find some minor issues, but didn’t take long to work around)

I also love SC/CS because like C++ its a bit more interactive that PD (as you can use the bela IDE)

btw:
the Beaglebone Black is not as powerful as the rPI, so you might have to scale things back
the new BeagleBone AI potentially brings alot more power to bela in the future

any specific questions , Im happy to answer :slight_smile:

(oh and if your into eurorack, Pepper is definitely work investigating :slight_smile: )

#94

In backing the Trill I’ve ordered one of the mini starter packs as well, so curious to see how comes on.

They’ve also come out with a new (browser-based) IDE:

It’s surprising to hear that the rPI is faster than the Beaglebone, as I would have pictured the opposite given their footprint/cost.

1 Like
#95

Ive backed trill too, im going to be building some kind of control surface for the modular :slight_smile:

yeah, i like the library function, and the general tidying up they have done.
though, i cannot see me using the new GUI features, as i rarely have the bela/salt attached to a computer except for coding… but i guess might be useful for debugging?!
(id like to know if there is any ‘overhead’ if you dont have a browser attached?)

i should be specific - its quite a bit slower than the rPI3 / 4 (not sure about rPI2)
first its only a single core, not quad …
but the other issue its FPU is very limited, which has been a big issue for me, particularly if you use something like PD/SC/CSound since you avoid floating point code. (when you write in C++ you can code attempt to code around the issue to some extent)
i suspect the price differential is partly down to volume, but also the Beagblebone in other aspects a superior board (e.g. the PRU)

anyway, that’s why im quite excited by the Beaglebone AI, its got a proper FPU, dual core A15- and also 2xDSP (c66) and 2x M4 co-processors.
currently Bela are looking at whats required to get it working with the existing bela capes
https://forum.bela.io/d/880-beaglebone-ai

one issue with it might be current draw/heating … but thats always a trade off (like the rPI4)

1 Like
#96

well, i have a different opinion there. norns engines in SC are very portable. yes, they conform to an API which includes “commands” - not key/value parameters, just thin wrappers around arbitrary OSC messages - the lingua franca of SC. (and the stuff being wrapped can be pattern generators, mini languages, whatever - the only thing we discourage is managing hardware I/O at that layer.) this is just the normal way to make SC code “embeddable,” and all the norns SC system classes do in the present architecture is collect and publish these OSC command sets. it’s an API i use with sclang, puredata, unity, and other stuff, all the time.

concrete example: here is an example of a fairly complex SC instrument (carl testa’s “sway” system.) it runs on norns but is completely agnostic of that fact. the Engine class just explictly breaks out a number of analysis and control signals, which i’d think would make it easier to adapt to the large count of discrete IO channels on the bela.

norns lua side, sure. much is UI and much is musical logic, and since we don’t enforce abstraction in the same way, it is hit or miss. i’d encourage anyone making interesting sequencers, &c, to modularize wherever it makes sense, but in general i don’t see it being done a lot.

2 Likes
#97

I’m not sure if you have you looked at/used the Bela supercollider api, but The Bela hardware interaction is done as Ugens, So server side not language side - so it’s seems converting that to norns OSC messages is problematic/inefficient - no?

Of course I’m not saying it’s impossible, just i suspect it’ll need quite a few changes.
Also as I mentioned above , the beaglebone is nowhere near as powerful as the cm3 used by norns - so it’s quite possible that many patches would not perform that well on Bela.

All that said, for sure, you could look thru norns engines or any other supercollider code for inspiration and ideas - and adapt code where possible.

#98

i see what you mean. in fact i first used SC on beaglebone (well, attempted it) in 2012 or so, and on bela when it was a cape. but no, i haven’t experienced all the excellent new stuff that the SC devs have been doing for the platform since 2016.

but to speak to compatibility: the bela analog oheyutputs are still exposed as the 2 main audio ports for the server - exactly like norns. (oh: they’re not, i read that wrong.), the digital pins are where things become different. and it’s true that interactions with the digital pins are only low-latency if on the server.

but, it is a simple thing to route DigitalIn and DigitalOut through the client, and control norns engines with them. that is what most of the bela examples do when they assign DigitalOut to a synthdef arg and control it with a PDef.

to get low latency on the server of course you need special bela code. norns doesn’t know about it, but that’s true of all other SC environments.

to speak to efficiency: i agree. they are different platforms and i certainly wouldn’t try to run the whole norns stack or even encourage anyone to think about it. but, just the SC component? it is not so far off. on norns the SC process is constrained to a single 1.2GHz core - same ballpark right?

my point was a little unclear i guess. internally, norns SC engines don’t use OSC messages. but the commands they provide conform to the format of OSC messages, not to some weird norns-only API.

i’m off to work… but all i really want to say is that there is no reason to completely dismiss the possibility of keeping things portable by design, or to scare people off from the prospect of working on that.

#99

unfortunately no,
BBB uses an A8 so its only got VFPlite, which means float performance is nowhere near the rPI.
(this is one reason the BB AI is such a step forward!)

I was not dismissing or trying to scare people off, just expressing an opinion based on what I know of Bela of how easy it might be - for sure the devil is in the detail, when you try is when you will know for sure!

but, Im platform agnostic… I happily use many different platforms, and like to be open/honest about them all - If the OP had talked about porting Organelle patches, or Automatonism, Id have similarly expressed my opinions on the viability and potential problems they may face.

#100

Sure. And I appreciate your sharing your experience. I did not realize they were still using VFPLite. That does make a revision attractive. (it’s surprising, because back 2012 or whatever, the same limitation applied to BB and the more attractive option was Blackfin if you were gonna be stuck doing fixed point anyway.)

But this can be said quite clearly: it’s likely that the best approach to SC code working on Bela is to tailor it to that platform’s constraints. (You have experience that speaks directly to that.)

I would also say that norns engines have a somewhat better chance of being portable to a constrained platform than some general SC code. (I have experience which speaks directly to this.) Additionally, specific steps could be taken to make norns engines friendlier for a wider context, and that’s a good thing to consider.

(Portability is on my mind. I have had a frankly insane two weeks getting some quite heavy analysis algos from x86 to stm32h7!)

#101

Based on my limited time with a BB AI (one evening before needing to focus on other things) - the BB AI runs way hotter at idle (uncomfortable to touch) than RPi4 idling…

#102

Interesting, I’ve resisted ordering an AI until I reduce some of my projects backlog - and hopefully this gives Bela time to update the PRU code.

I’m hoping with a reasonable heatsink the AI will work for my application, but we’ll see.
In the meantime I’m happy with the BBB now my expectations are more aligned with its abilities :slight_smile: