Orac 2.0

thetechnobear · Apr 19, 2019

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.

AndyCap · Apr 20, 2019

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

thetechnobear · Apr 20, 2019

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

giuliomoro · Apr 20, 2019

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.

thetechnobear · Apr 20, 2019

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

giuliomoro · Apr 20, 2019

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.

thetechnobear · Apr 20, 2019

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

thetechnobear · Apr 20, 2019

@AndyCap
yeah, so I broke the digital input at some point

here is a new version of bela.pd which fixes it (just copy to ~/Bela/projects/orac)
https://raw.githubusercontent.com/TheTechnobear/Orac/dev/Salt/orac/bela.pd

(this will obviously also be fixed in the beta 3 release in next couple of days )

with this note cv in also works... so for me everything is working...

AndyCap · Apr 21, 2019

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:

Align all memory blocks to 16 bytes.
Make sure compiler understands that loops are divisible by 4. ((loop_count >>2)<<2)
If possible use intrinsics.

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

giuliomoro · Apr 21, 2019

AndyCap Try enabling NEON run fast. https://pandorawiki.org/Floating_Point_Optimization

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?

giuliomoro · Apr 21, 2019

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.

AndyCap · Apr 21, 2019

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?

AndyCap · Apr 21, 2019

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?

thetechnobear · Apr 21, 2019

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 )

AndyCap · Apr 22, 2019

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.

AndyCap · Apr 24, 2019

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?

thetechnobear · Apr 24, 2019

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.

AndyCap · Apr 24, 2019

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

AndyCap · Apr 24, 2019

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

thetechnobear · Apr 24, 2019

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 )