#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:

#103

I just finished assembling a Pepper kit I bought last year. Thereā€™s a rev 2 that has audio outputs with an amplified signal from an added op amp. The nice people at Queen Mary University of London mailed me an adapter board free of charge because I bought a rev 1 before the rev 2 was released.

Anyhooā€¦Iā€™m into the possibility of at least getting monome serial devices to work on Bela. Thereā€™s only a single USB host port but it could be interesting to port some of the code from monome eurorack modules to a Pepperā€™d Bela. Iā€™ve always been intrigued by the demo videos of Ansible. I think itā€™d also be a thing to make Bela versions of some Mutable Instruments code.

2 Likes
#104

Bela is linux right? (Oopsā€¦ maybe Iā€™m wrong there?)

Serialosc or libmonome would get you connected to grid, etc. (there seem to be some people up-thread that have tried this)

Thereā€™s also ORAC for bela so you could get a number of MI implementations that way as well.

1 Like
#105

Bela is running Linux with a Xenomai real-time kernel. It really should be a better choice for audio projects than a raspberry pi, but it can be harder to treat a Bela like a computer (in my experience peripheral support was more of a challenge than it is on RPi, but then again, itā€™s been a while and Iā€™m not sure how things may have evolved in the last couple of years).

1 Like