very nearly there, here is a little taster of what you can expect ...

here is the plan...

Tomorrow :

  • Orac 2.0 new features / walkthru video (relevant to all platforms)
  • Orac 2.0 Remote Clients (relevant to all platforms)
  • Orac 2.0 Organelle video
  • Orac 2.0 Organelle beta release

Thursday :

  • Orac 2.0 Raspberry PI video
  • Orac 2.0 Raspberry PI beta release

Friday:

  • Orac 2.0 Eurorack video
  • Orac 2.0 QuBit Nebulae & Bela Salt beta release

As its just me, Im needing to spread things out a bit to ease my workload, and let me finish off a few things in the background.

Beta: so Im labelling this as a beta, but it could also be thought of as a pre-release.
the idea is to get your feedback whilst I have some time to focus on Orac.
so if you use Orac, I highly recommend you install it and help me refine it.
after the release, Im likely to take a bit of a break from it (its been very time-consuming lately) - so the beta is a bit of a time-limited opportunity.

as well as feedback I also really appreciate if we could build up some presets that I could include as part of the final release. I think this would be really cool for new users.

in prep for friday , here's what you can expect in 2.0 πŸ™‚

New features and overview of Orac 2.0

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?