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.

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