ok, its eurorack day, so time to release Orac 2.0 for Bela and Bela Salt 🙂

ok, I should manage expectations here a little, the performance on Bela and Bela Salt is not what I'd hoped for (*)

I spent a lot of time trying to improve it, ensuring it was not triggering CSW, but thats only help to a certain degree.

but it seems like PD just gobbles up resources on the Bela, compared to both the Organelle and rPI,
so adding more than a few synths and fx gobbles up cpu quickly. (and Bela gets pretty unresponsive when it hits cpu limits)

(the slightly good news, is when there aren't heavy synths/fx in use it behaves well, showing my underlying architecture is not the cause - its just the dsp load of certain modules)

but, what Im hoping is that perhaps with it out in the community that perhaps we can improve it together, as potentially it could be a really great way to use Bela.

a couple of areas for improvement:
- I need to recompile ableton link, I tried the pi version, and its was throwing CSW
- whilst all my externals and libraries (Kontrol/Mec, Mutable Instrument externals) are compiled for Bela/Salt,
Ive not recompiled the externals used by some of the modules. (e.g. things like moog~) , so there may be some improvement to be had there.

(*) so you'll see the video mainly concentrates on the Nebulae, this is because really the way things operate is identical between the two - but given the performance was so much better on the Nebulae it made sense to use it for demo purposes 🙁

(irony is, Ive spent so many days trying to get bela working, and improve its performance - yet got the nebulae going in about a week 🙁 ... of course, partly as the rPI work was already done, and the modular extensions were done for Bela)

6 days later

Beta 2 released on patchstorage.com for bela and salt.

also released a new getting started guide.

is anyone using it? or shall i forget salt/bela due to lack of interest?

it'll still be available to build via GitHub.com , but its obviously takes me time to actually build and upload the releases, not much point if no one is using it 😉

https://github.com/TheTechnobear/Orac

Hi Mark,
thanks for your continued efforts! We have a been under heavy load this month, and only had time to go through a couple of your videos, but we are looking forward to trying this out in the next couple of weeks: it's in our schedule.

    giuliomoro thanks for your continued efforts! We have a been under heavy load this month, and only had time to go through a couple of your videos, but we are looking forward to trying this out in the next couple of weeks: it's in our schedule.

    cool, no worries - I know we all have lots on out plates, so really just wanted to know if anyone was interested.
    (I do know of one person thats got it running on a Bela board,)

      Hi Mark,

      I have had a quick look through the videos, it is all looking pretty good.

      I have been very slack in looking at Orac but this weekend is going to be Orac weekend with the Organelle and the Salt being brought into play to have a look at all this work you have done.

      It was quite interesting watching those videos with a brandy or two, I have only ever heard your voice and never seen your face, so I had guessed your were a youngster (< 30 in my addled brain), even thinking this I was impressed with the amount of work you have put into this.

      Now knowing you are of a more mature vintage I am even more impressed that you have spent all the time required to get this going, nice job!

      As a side, how is the Nebulae what processor has that got?

        AndyCap

        lol ... yeah 'maturity' has its advantages ... esp. when it comes to coding 😉

        as I said above, I was just genuinely interested if anyone was interested in this or not, its ok, its ok, if not 🙂
        this is kind of 'different' for the modular world, and there are many debates on 'generic modules' in Eurorack,
        and the Percussa SSP , gets both love and hate thrown at it...

        but Im keen to explore it, and find out if Orac is useful in this format, and also in what kind of form. (perhaps it has to be different) - this is also true on the rPI, does it have to change form to work better in headless format?

        I'm also intrigued about its potential role with Bela (non-salt) as a way to build an interesting bespoke instrument.
        (given its so easy to add hardware to bela)

        AndyCap As a side, how is the Nebulae what processor has that got?

        it's a rPI3 running arch linux. so its powerful.

        its pretty good for CV input , but the PD interface is a bit quirky in places... and not really 'fully featured'
        but mainly because Qubit I think have been balancing the Nebulae as a 'ready to use granular synth' , with a bit of DIY on the side - in some ways I think that is great approach - its granular synth is fantastic, well worth its price alone (imo) , so being able to extend it does feel like a bonus ... and frankly I think only a subset of users ever bother!.
        (no cv output is a bit of a pity, but again, its because it was not needed for its 'primary' purpose)

        so a very different module to Salt, they don't really compete - esp. for me, as for some reason, I seem to alway be using my Salt for CV output (*) , rather than audio.. I guess, probably this will be true for Orac too, I will tend to use Orac on Salt as a CV processor.

        notes:
        - Ive not created the CV output module yet, ran out of time, but its a trivial bit of PD 🙂
        - you'll also find, Ive got an alternative cv input modules available for salt/bela (modules_exp), but they were causing me trouble, so I went for a simpler implementation for the beta. I'll review these at some point, as I think they would be more cpu efficient.

            Hi Mark,

            So first I tried installing Orac on my frankenstein Organelle, after that failure I started with a new SDCard and the image from C&G.

            I messed around with version 1 for a while so I could see how that all worked.

            Then I installed version 2, I think it is a much more refined version that the original. Nice job.

            So then on to the Bela and some confusion has set in!

            I can hear the drums from the initial demo patch and mess with the parameters over OSC.

            I can not work out how to trigger a1:Brds, infact I can't get any of the trigger inputs or CVs to affect anything at all including midi learn/mod learn.

            Do you have some pointers for me about how to use it on salt?

            Also is Salt+ supported?

            Cheers

            Andy

            so you should be able to just send in notes on midi ch1 , to trigger braids.
            if thats not working, then that suggests something is not working with the midi controller/pure data.
            since i just use things like [notein] [ctrlin]

            does PD need configuring at all for salt/bela for midi?
            as far as I remember it just connects to the first midi device - no?
            (do you have it working with other pd patches?)

            I admit not Ive not been playing with midi and pure data with salt... but it was working with supercollider last time I tried ... I'll give it another go.

            anyway, that explains why midi learn is not working....

            but mod learn, should be working, as on the eurorack video... (around 11:00)
            select the CV IN module,
            select mod lean, turn up amount
            move param on module
            move cv
            unselect mod learn

            what I do to learn, is to initially use the knobs on salt, once that works - you know sending in CV is the same
            so basically looks exactly the same I was doing on the nebulae.
            (except they are just name 1-8 )

            note cv in, pretty sure I tested this...
            as its feeding notes, you obviously have to place it at the beginning of the chain - like i did with seq2 in the getting started video.

            yes, I always use Salt+ , I guess it should work without, but of course some of the CV in won't work 😉

              thetechnobear does PD need configuring at all for salt/bela for midi?
              as far as I remember it just connects to the first midi device - no?

              It connects to hw:1,0,0, if present when you start the patch. You can check with amidi -l whether the interface is listed and whether it actually is hw:1,0,0. If it has a different ID/name, you can set it when starting the patch with something like:

              [loadbang]
|
[hw 0 0 0(
|
[s bela_setMidi]

              as exemplified here.

              thetechnobear yes, I always use Salt+ , I guess it should work without, but of course some of the CV in won't work 😉

              I have no idea how your CV learn works, but if it is anything like a "traditional" "MIDI learn" (i.e.: select one virtual knob, move one physical knob and they are paired), then it is unlikely to work without Salt+: the unconnected inputs are left floating and the readings regularly oscillate across the whole input range.

                    ok, so just tested here...

                    midi is working fine, both note and learn
                    a cv in is working fine (with CV IN)

                    cv note in , seems not to be working , I need to check that in a bit more detail.

                    giuliomoro unlikely to work without Salt+: the unconnected inputs are left floating and the readings regularly oscillate across the whole input range

                    they seem to be stable on mine ?!

                    why would you let them float? its normal for eurorack modules to tie unconnected inputs to gnd (0v),
                    otherwise you'd have to plug something into every cv jack... why would salt be different?
                    esp. since its pretty normal to want to use the knobs without necessarily putting a cv into the jack,
                    ... and we are not able to differentiate between the cv in, and knob since its just an offset?!

                    anyway, the way mod learn works, is each CV input has an attenuated amount and offset,
                    so if others are fluctuating thats not an issue, set amount % and offset to zero for all others, then even if they are jittering, they'll still be zero 😉

                    if you need to set the midi device, as per giuliomoro post, you can simply do that in _main.pd , as you'll see its just a container patch, so nothing complex in there 🙂

                          thetechnobear why would you let them float? its normal for eurorack modules to tie unconnected inputs to gnd (0v),
                          otherwise you'd have to plug something into every cv jack..

                          You may have misunderstood me: on Salt and Salt+ all the inputs are half-normalled to GND when no input jack is present. However, without Salt+, CV inputs 5-8 are left floating.

                              giuliomoro ah, that’s no issue the as you have to explicitly enable them by turning the amount % up from zero

                                Hi Mark,

                                Thanks for the info, looks like it was mostly user error here as I expected the Demo patch to be set up for CV!

                                I will have another try today with the CV modules!

                                Concerning performance as well I dragged out some tests I did before, I guess you probably know all this but just incase:

                                1. Align all memory blocks to 16 bytes.
                                2. Make sure compiler understands that loops are divisible by 4. ((loop_count >>2)<<2)
                                3. If possible use intrinsics.
                                4. Try enabling NEON run fast. https://pandorawiki.org/Floating_Point_Optimization 
                                  #ifdef __ARM_NEON
void enableRunFast()
{
  printf("NEON enableRunFast\n");
  static const unsigned int x = 0x04086060;
  static const unsigned int y = 0x03000000;
  int r;
  asm volatile (
                "fmrx  %0, fpscr      \n\t"  //r0 = FPSCR
                "and  %0, %0, %1      \n\t"  //r0 = r0 & 0x04086060
                "orr  %0, %0, %2      \n\t"  //r0 = r0 | 0x03000000
                "fmxr  fpscr, %0      \n\t"  //FPSCR = r0
                : "=r"(r)
                : "r"(x), "r"(y)
                );
}
#endif

                                Here are some sample results for 65536 float multiplications, 10000 iterations:

                                compiled with:

                                -O3 -Wall -c -fmessage-length=0 -Wpointer-arith -Wunused-result -fpermissive -march=armv7-a -mtune=cortex-a8 -mfloat-abi=hard -mfpu=neon --fast-math -ftree-vectorize -ftree-vectorizer-verbose=10 -MMD -MP -MF"src/TestFloatSpeed.d" -MT"src/TestFloatSpeed.o" -o "src/TestFloatSpeed.o" "../src/TestFloatSpeed.cpp"
                                type       time       per sec
================================
C          124.004s   5,284,990
C 16 align  53.347s   12,284,852
intrinsics  39.251s   16,696,645

                                  Not sure why this is referred to as NEON runfast: it is actually VFP runfast from my point of view. This is already enabled on Bela: https://github.com/BelaPlatform/Bela/blob/master/core/math_runfast.c .

                                  AndyCap C 16 align 53.347s 12,284,852

                                  Do you make it explicit to the compiler that you use 16 byte align? Or is the generated code capable of choosing the "fast" path at runtime depending on the alignment?

                                      AndyCap Make sure compiler understands that loops are divisible by 4. ((loop_count >>2)<<2)

                                      (I also tried (loop_count & ~3)) does this really help? I never managed to produce meaningful improvements with this, and I thought the reason was that clang was always unrolling loops such that it would have a SIMD path for multiples of 4, and then handled the 1 to 3 leftover iterations with scalar instructions.

                                          For the 16 type align I am just using posix_memalign()

                                          For the loop count that is something you told me to do a while back so I have stuck with it 🙂

                                          Back to orac.

                                          I'm having some issues here, suddenly the node process will jump to 85%, that combined with orac is killing bela.

                                          I don't have the IDE running in a browser, although it was used to start orac.

                                          Any ideas on this?

                                            Marc,

                                            I have been playing around a bit and getting into a state!

                                            How do you Mod Learn when there are multiple modulations set up and running?

                                            Is there a way of removing modulations?

                                            How does NoteCV IN work?

                                              AndyCap
                                              you can do mod unlearn - by setting the modulator to zero...
                                              i.e.
                                              mod learn on
                                              touch parameter to unlearn
                                              turn modulator source (e.g. knob) to zero
                                              mod learn off

                                              modulators - so to learn a new modulator (when you have others) simply stop modulating existing ones before you try to learn a new one (easy way is to turn amount % to zero) .

                                              its a bit of fiddly when you first start, but once you've done it a few times it was fine...

                                              notecv (make sure your using my new bela.pd as above)
                                              put note cv in a1, synth in a2 - use t1 as trigger, cv1 as v/oct input.

                                              mid-term, im going to replace it with a mod matrix type system, which allows for mixing of modulations etc.
                                              but that requires a bit more underlying work, and on the UI.
                                              so i wanted a quick solution for 2.0, so i didn't waste too much dev effort on something that will be replaced, and this was quick, as was the same as midi learn - and required minimal 'ui'.

                                              yeah, i saw the comments about optimisation, but as far as i can tell thats just not practical in this case...
                                              i cannot optimise libpd, and it would be a huge amount of effort to optimise existing PD externals i didn't write....
                                              (can you imagine trying to go through elements or braids from MI?)

                                              ... and my externals/code are non-dsp, so don't have the maths/vfp issues anyway.

                                              of course if there is some way i can compile existing code, and get better results (I think im using all the compiler options discussed above), or some how tweak libpd - Im all ears 🙂

                                              (one option discussed before is recompiling PD to allow for bigger buffers sizes that 128, not sure if thats particularly desirable though)

                                              at the end of the day it does work reasonably, well if you don't go over board with fx and synths.

                                              ...and part of the reason its fails more dramatically that on a rPI, is that Xenomai will really let you take virtually the entire CPU, so when you overstep the mark - you tend to get 'locked out'.
                                              (this is not unique to pd, or orac... its generally true .. ive done the same regularly with supercollider 🙂 )

                                                  Hi Mark,

                                                  Thanks for all the info, I'll get that latest version and have another go.

                                                  Concerning performance:

                                                  I have looked into the memory alignment in gcc&clang to see if there is a simple way of enforcing 16 byte alignment without changing code, there doesn't seem to be a catch all way of doing this though.

                                                  giuliomoro (I also tried (loop_count & ~3)) does this really help? I never managed to produce meaningful improvements with this, and I thought the reason was that clang was always unrolling loops such that it would have a SIMD path for multiples of 4, and then handled the 1 to 3 leftover iterations with scalar instructions.

                                                  I have just had a read about this and you are correct, both gcc and clang do not need this hint to vectorise but it does stop them producing extra code to handle any leftovers.