CC 4 = foot controller
CC 11 = yeah, its expression BUT by the midi spec its related to volume (% of cc 7)
but in fairness, CC # are abused so much theses days their meaning is not really that important
44k vs 48k, actually its should be better on PiSound, as the MI modules are generally 48k,
I guess your specifically talking braids? I think that has a small ‘hack’ in the PD code, to make it work on the Organelle. (But I need to double check this, also with a tuner to see whats going on)
as it happens there is stuff in the MI code which kind of expects it to be 48k,
what VCV rack does to handle this is to to up or downsampling - but that is way to expensive on an Organelle or PI…
I’ll take a note and have a look… see if I can make PD auto detect and adjust.
(I dont want the modules to vary in code, just way to much maintenance effort for that )
oh, lots of ways … i run natively on a mac, but thats a bit tricky to do as a first step
on the organelle its become quite popular to do this over VNC (ever since I created an installer for tightVNC server) - that probably is the easiest way
alternatively connect an HDMI monitor, and keyboard and fire up the desktop.
from there its simple
a) stop orac service, so you can run it manually
(systemctl stop orac)
b) run orac from terminal
as your doing development you dont really care about ‘performance’ and with gui it will be worst anyway
so simply
cd /usr/local/orac
pd mother.pd main.pd
should be all you need… (iirc)
most of the interesting stuff is launched off of main.pd, but don’t close mother.pd as its the thing interfacing orac to midi.
NOTE: you will need something to switch modules etc, as orac dynamically re-writes the patch when loading modules
Definitely those, and also reload current preset. So you set a starting point that you can easily return to when things go haywire (that could be part of the performance!)
Slightly O.T. but…
I was laying awake just thinking how nice it would be to have an envelope follower as a modulator - wondering how that might be implemented?
sending current pgm chg will reload preset…
perhaps this is good enough?
but interesting…
(hmm, reminds me, I want to add all notes off support!)
yeah, you’d have to put it in one of the audio slots (or p1/p2), so it gets audio, but nothing wrong with that
implementing , basically just use [env~] , you can use one of the existing modulators as an example (main thing to bare in mind is the output is 0…1)
if you take either lfo or macro as a starting point you’ll find modulators are very easy to implement - they only have to generate modulation values, and stuff them into a simple pd message - easy
all the other stuff like learning, updating other parameters is taken care of by orac!
So this isn’t working for me. Specifically I get “Failed to add match ‘orac’: Invalid argument”
Running it on the command line from the pi using HDMI.
I made my own patch to check the MIDI input my controller is sending.
I’m definitely sending CC69 on channel 16 while the remote client is on Seq2 and still not getting any AUX action so I’m not sure what’s happening there.
EDIT:
Actually I managed to get something happening setting the CC#69 button to output -63 Low and +64 High with a toggle. It plays two or three of the notes entered and then stops. I’m assuming it is supposed to loop right?
It also seems that my MIDI controller PGM Change pot only sends on the keyboard MIDI channel unless I create a specific button for it. So having a next/prev/current CC would be very valuable for me at least.
Setting a button to send a specific PGM Change seems to work for demo1 and demo2 but the new presets don’t load at all from a PGM Change for me. At this stage I don’t know what i’m doing wrong. Getting to see what ORAC is getting and how it is responding would definitely help me troubleshoot.
Great ideas for the program change messages! This is very useful functionality as I’m fiddling on a novation mini that doesn’t send them! How easy is this to do by sending OSC messages in the form of utility modules, internally to Orac? Can some of these beta ideas be solved by just making more patches? And where is the main repository for Orac2 patches?
you can still make this work, just set active midi channel to your keyboard channel BUT turn note and ctrl OFF , so orac does not send these to the modules.
(then things like program change, aux, fs, esp will all work on that channel)
ok, I’ll look at next/prev preset - though, as I said, Im want to take care not to have too many messages,
it’ll be a support nightmare explaining this to people.
note: it will be on the active midi channel - i do not want to do things off this channel
you do not need to send OSC messages within modules/orac…
you can simply use PD messages, you only need OSC for remote clients!
things like program change (= select preset) , next preset, prev preset , save preset
are all available as pd messages that can be sent to the rack.
so you could do this in modules.
if you looking in main.pd, and the sub patch ‘rack’ you will see the some of these.
sorry there is not a full list available, as I’ve been the only one using them…
note: this is left for user/community modules - Im not doing to do this, as whilst I recognise some controllers have limitations, I cannot code for every controller, partly as I don’t have them to test with, but also there would be so many variations, it be impossible for me to maintain…
so basically the idea is Orac will have a ‘reasonable’ set of options with defaults, and then users can extend this… to deal with their particular controllers.
again, if the community, wants to help develop the documentation that would be very helpful!
yes, most things discussed here could be done by user modules.
and as above, there is certainly a point, at which things are best done by the community and shared.
obviously some other things , should be in the ‘core’ orac, as they are needed by many, so it’ll be a balancing act.
currently there are Orac modules on patchstorage.com under Organelle.
I think most of these (except the C&G ones) have not been updated to 2.0 yet.
@Pranciskus / @Giedrius have suggested that perhaps Patchstorage should have an Orac category so that all things orac can be found easily and because Orac modules and the remote clients are cross-platform.
What do others think?
note: my only slight issue with this is ,
“Orac for Organelle” will not then be findable if you look at Organelle patches…
so perhaps the non-cross platform part should be in the platform part
e.g.
Orac for Organelle (Organelle)
Orac for Nebulae (Nebulae)
Orac for rPI (Orac ) (as no general rPI category)
Orac Remote Osc Clients (Orac ) ( useable by Orac users on all platforms)
Orac modules (Orac) ( useable by Orac users on all platforms)
another option is to just use #orac on patchstorage, to search
( I think most will be putting orac as a tag)
but that doesn’t solve the issue that modules and osc remote clients are being put under ‘organelle’ as theres is no logical place to put them
ok, so beta 1 didn’t have that many bugs reported, and for beta 2, I currently only have 1 bug so far - so mainly betas have been about tweaks to features due to feedback (which has been useful)
but overall its looking like Orac is stable,
so my plan is to wait a few days is to see if I get any more bug reports, and implement the tweaks Im planning.
if no big bugs (which seem unlikely now) , then its likely Beta 3 will be the final beta before release, and as such I will limit the changes I make between beta 3 and the release to essentials/critical bugs
(this is standard development practice to ensure you don’t break anything for final release )
what this mean is, the next few days is the best time for you to make suggestions, or report bugs - so that i can get them into beta 3, and so release.
note: Im not planning on implementing new modules or major feature changes during this beta - they will come either for 2.x or possibly I will release modules separately, that I will then roll into a 2.x update.
when 2.x will be done, will depend on urgency of changes (e.g. a bug being found) and my time
so please, if you use orac, try to spare a small bit of time in next few days, to check things are working as you expect.
The catch being that then I can’t use the keyboard.
I’m going to have to look at what the journalctl stuff is reporting because the results i’m getting don’t make sense. Tomorrow though as it’s bedtime in the land of Aus.
So far I’ve found no problems except with modules needing Aux.
you will use the keyboard thru midi from the chain input.
this is the recommend approach anyway…
(since when you don’t have a display, its difficult to know which module is active)
sorry, but here is no way, Im opening up Orac so that people start using the active input channel for midi by default.
I spent a ridiculous amount of time during Beta 1 - trying to get people to understand why setting setting active ch = 1 and chain midi ch =1 was not correct. it was obvious I was fighting a losing battle, most even when i explained it, still didn’t ‘get it’, and even if they did, a day later Id have to go thru the same thing again with someone else.
and it’s not about lack of document, it’s just simply that people don’t really have a good sense of ‘active’ module … esp. when its not on the Organelle (where at least i can say its the one the screen is showing),
and initially using the active channel SEEMS to be the right thing.
anyway, as i said, im changing the default, you can turn it back on if you want ( assuming you know what you doing ;)) , and its saved with the preset - so its not like you have to keeping doing it
So, I haven’t been able to connect Push 2 to MEC on the Raspberry Pi w/ pisound.
aconnect -l
…shows that Push 2 is connected.
sudo systenctl status mec
…shows that mec is active.
No errors.
But it shows that we’re running osckontrol.json, which I believe is the wrong file. I have to load a different file (push2kontrol.json? i’m guessing at the name) on Organelle, which coincidentally functions appropriately with the Push 2.
So… I probably need to edit some sort of startup/config file?
Hello (almost happy easter). I’m working on a simple “hands-on” orac project.
As you can see from the video (sorry, I don’t have a tripod) it is just a simple interface made of 5 encoder rotary encoders (with a button) an oled, a teensy lc. (and… a raspberry pi with pisound).
so far part of the code is in a pure data patch and another part in a python script (it receives osc data from pure data and print to display via i2c). I’m willing to share what I’ve done so far (i just need to clean it a bit) cause I’m sure there is plenty of much clever ways to handle the code and the interface (I’m a super noob)
cheers!
)
