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.

          Hi Mark,

          It's all up and running on the bela, very neat 🙂

          thetechnobear 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.

          This sounds like a very good idea, it is very easy for me at least to mess up the modulations when trying to set them up.

          Is CV out coming in beta 3?

          Also, how do you go about developing Pd for the Bela, especially with externals?

              yeah, its easy to mess up the modulation stuff...
              of course, what you could do is save as a preset, then go edit the json file...
              (~/data/orac/presets/presetname/params.json)

              AndyCap Also, how do you go about developing Pd for the Bela, especially with externals?

              good question!
              so Orac is completely cross-platform, so 99% of it, I write, test and debug on a mac...
              I use the Push2 to mainly control it, but you can (now) also use the PD osc client.

              to develop externals, including the main KontrolRack (what people 'see' as Orac) - I use CLion which you can get a free licence for as an open source project(!) and is fantastic.... in debug mode, you just launch PD, but of course its attached to your C++ externals. (not unusual for debuggers, but still cool)

              then there were only 2 bits I couldn't do on the mac
              a) Xenomai specifics - which we discussed on this forum.
              mainly this was compilation issues, and getting the xenomai wrapper to work, and then dealing with a few issues around threads (I use std::thread, which don't wrap entirely properly without a tweak)
              obviously, I try to keep this 'specific' code as small as possible, to keep it cross platform.

              b) PD modules
              just a matter of interfacing to bela/salt, yup different due to pin numbers/volt ranges (argh!),
              but this is only a matter of looking up the way bela/salt CV is interfaced in PD, which @giuliomoro and crew have documented really well.
              ... again these then just go into note and modulation inputs, which are cross-platform, and so already tested 🙂

              for the actual bela pd modules, I tended to have PD running on the Mac to do the work, and just scp'd the files across to pick them up - the nice thing about Orac is if you reload a module, it will pick up the changed pd files, so you don't even have to stop orac!

              this is the beauty of cross platform development for me...
              you can develop quickly on a proper desktop environment and then just deploy on environments where its not quite as 'fully featured'. ( I guess its just like treating bela as an 'embedded' platform where you do similar)

              I'm just about finishing up on another project for Bela/Salt which you'll probably see by the weekend 🙂
              that by contrast is more 70% cross-platform , 30% salt/bela - as its mostly about CV, buts its all C++.
              there Ive been using the Bela IDE a lot... which has been cool, and pretty rapid to develop with!

              at some point, I did have to chuck the bela code into a temporary CLion project when I wanted to refactor it.
              I perhaps should have done its setup a proper sync between desktop and salt, as whilst I like the Bela IDE, its obviously not as fully featured as CLion, or Sublime text.
              but of course, on the flip side they dont support the bela Scope, which is an awesome tool for debugging 🙂

              hard to say, the bela IDE is really convenient, and quick to get things done - so perhaps treating refactoring as an edge case is correct.

                Thanks for all the info, could you point be at the bela PD documents, the stuff I am looking at uses Heavy which I guess is the old way?

                Can you have a tab in CLion with a web browser?

                If so point it at http://192.168.7.2/scope/ and you can see the scope.

                It works in Eclipse:

                alt text

                Don't worry about the PD docs, Giulio has answered in the other thread.

                no, i don't think CLion has an internal browser, but easy enough to have one running alongside 🙂

                ah, you have remote debugging working - thats cool...
                are you doing cross-compiling, then sending the binary to bela for execution/debugging...
                that would be a really slick way to integrate...
                (hmm, perhaps we should really discuss this on a separate topic 🙂 )

                Yep cross-compiling, it isn't too much of a chore to setup.

                All the info to setup eclipse Is here: https://github.com/BelaPlatform/Bela/wiki/Compiling-Bela-projects-in-Eclipse

                Also a cross compiler is there with gdb to download, I built this all with crosstools to match GCC and GLIBC versions with Bela.

                I just checked and clicking on a pd source file in Eclipse opens it up in PD as well.

                The Scripts for syncing the includes and libs from the bela are not setup to use libpd though, I am going to change the scripts and test building/debugging a pd based project with eclipse...

                libpd is installed on the board on /usr/local/include/libpd/ and /usr/local/lib/libpd.so* (don't remember if there are any symlinks).

                23 days later

                new version of Orac 2.0 release (release version - out of beta 🙂 ) over at patchstorage as always

                  4 months later
                  a month later

                  Hi, thanks for the software! has anyone used this on the latest bela firmware? I have seen on other threads there are performance issues but my bela seems to even have problems with the demo patches (60% cpu for the drumbeat one, and the polysynth one locks it up, no terminal response). I wonder if anyone else is having the same issue?

                  hmm, I only yesterday updated my Bela/Salts to the latest software, and not had a chance to test.

                  Were you running Orac before you updated the software? are you sure its deteriorated?

                  unfortunately I didn't really take any measurements of what the load was on the previous version of bela software,
                  so I cannot say if the number you mention are worst or not.

                  I'll give a go when I get a chance, but Im not sure they'll be anything I can do to improve it...
                  as Ive mentioned on other threads, really its down to poor floating point performance on the BeagleBone Black (due to using VFPLite) ... and so libpd is not performing well (and I cannot optimise libpd) for large/complex pd patches like Orac - this is why the BeagleBone AI is really exciting to me 🙂

                  but as i said, when I get a chance, I'll take a look see if something odd is going on...

                  Were you running Orac before you updated the software? are you sure its deteriorated?

                  No I am a complete newbie, just trying things out before getting into the weeds. I am not sure how well the previous version performed. I might do some more testing and get back to you.

                  Beaglebone AI

                  Hmm, I don't know much about this, would it be a drop in replacement for the beaglebone black? I guess that would make it a neat upgrade for my pepper once it's built then!

                  18 days later

                  Thanks for the work. I tried installing ORAC on the Nebulae v2 but wifi doesn't work. I did edit the name and password in the wlan0-wifi txt file. Then I ran the 3 different inst files on Nebulae, but no wifi.
                  When opening the sd card from nebular on a different Linux desktop, the .inst files are copied ok. I didn't see the wlan0-wifi copied to /etc/netctl, should it be there?
                  When connecting a HDMI cable to Nebulae v2, there is no display. How did you develop/debug on the Nebulae? Is serial the way to go?

                  Yes config should be there - if its not copying WiFi setup , sounds like your not running WiFi script?

                  Iirc the way I worked this originally was connecting via Ethernet , I think this works ‘out of the box’

                  (HDMI doesn’t work, doesn’t have the drivers loaded)

                    thetechnobear I did run all the 3 scripts (including WIFI) several times. Somehow the script is not running or copying the files properly. It would be great to have a log.txt (on the USB stick) to verify output. Thanks for the tip, I wIll try the ethernet approach instead.