#77

The Bela IDE runs in the browser at the fixed address of http://192.168.7.2, which means you save CPU by virtue of the editor running as client-side JavaScript on your desktop/laptop. You edit your Pd patch on your desktop/laptop as normal, and it will transfer to Bela and start running when you save it, when using our watcher script (https://github.com/BelaPlatform/Bela/blob/dev-workshop/scripts/workshop_watcher). Or you can drag and drop the patch onto the browser window.

In terms of visual feedback, the Bela IDE features a text editor, console and oscilloscope (more on the IDE in this paper https://qmro.qmul.ac.uk/xmlui/bitstream/handle/123456789/26166/45.pdf).

And, yes depending on what the ‘visual elements’ are; LEDs and LCD screens are a possibility for example. The HDMI capabilities of BeagleBone are not available on Bela currently, this was not a priority initially as the graphics would consume CPU that we wanted to preserve for audio.

1 Like
#78

Hi, I’m considering using Bela to play audio files on 12 audio channels. would this work, or do i need something else ? What i don’t get is if it’s only the audio extension or if it contains the “core” platform as well.

Thanks for help !

#79

Hi @chapelierfou, that is a ‘starter kit’ which includes the whole platform. I agree that page is a little ambiguous, thanks for pointing that out!

You can always reach out to info@bela.io & forum.bela.io too.

#80

Thanks,
I got in touch with Bela and they replied me the opposite. So I’m even more confused…

#81

It doesn’t do 12 channels but did you see the Bela Salt module?

1 Like
#82

My mistake, in this case they were right and I was wrong. I had assumed you meant if you added the accessories to that order!

1 Like
#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