so excited to test this out later on!! Thanks @thetechnobear , Awesome
Yeah polybeats I need to store keyboards status , so it can be redrawn when you switch back to it.
Main change from 1.0 is less boiler plate code needed, look at a 2.0 one and remove the excess from 1.0 (mainly remove kontrolmodule)
( what’s cool is the module type/id is not coded, so to create a derivative module, just copy directory and rename it - simple!)
Notes now get a 0 0 0 , last float is voice # , 1.0 often will work ‘as is’, but look at a 2.0 synth for proponer handling for mpe etc.
Preset storage for things like sequences, see seq2/punchy
Sample manager - check one of the samplers
These might initially look complicated, but you should be able to just copy the code out to your own modules.
Oh, and all usermodules should now NOT be mixed in, place them in /media/orac/usermodules.
(Directory already exists)
remember to put in a category (synth).
If it exactly matches an existing ‘factiory’ modules name/category it will override it. Useful for bug fixes
This have got to be the most amazing extension of a hardware product EVER!! The Organelle is now so completely different and improved compared to the instrument I unpacked little over a year ago!
A simple thanks cannot express the gratitude this community owes you!!
I am having trouble using the remote pd client. crouton linux (ubuntu 16.04)(pd 0.49), can ping ‘organelle’, but only ‘organelle.local’ works in the actual message box.
no errors in the pd console after deleting externals folder (was given ELF error) and using deken installed mrpeach, but the client itself is empty and unresponsive. its says “m0:Polybeats” in the top line of the menudsp.pd window,
none of the buttons seem to be respond and still no errors in pd console
ps. netsend box is toggled in [pd connect]
ah, yeah I left the PI ones in there … its a pain that generally PD uses .pd_linux for different architectures!
did you start mec ? (see Orac 2.0 for Organelle video - in the introduction)
as for organelle, or organelle.local … it’ll be whatever your OS uses, this is just using connect,
no magic there…
one thing I have found for some OSs is if you try a wrong name it will take ages to timeout,
so if you change the hostname, its easier to stop pd and restart.
(on other OS’s its fine, and unnecessary)
as for the above… this shows that no data has been received, so its one of :
a) it cannot connected due to hostname (you can also try ip, but again should be unnecessary
b) mec is not running, as so therefore the port is not available
(these both you’d expect a non connection - but may take a while to get it)
c) orac is not running… so it doesn’t have rack info yet, and so there are no pages/modules to navigate
So I hadn’t started (or installed) mec! That was my bad, but I tried very quick before work this morning and it still seemed to be an issue. Organelle receives pings, no pd console errors, but “empty” client.
given how you broke things down it must be an issue a), and I am thinking right now maybe a port forwarding issue? which is strange as I dont usually have to forward anything for osc stuff at home.
This is also likely because I also have a pisound/patchbox setup and I seem to have the same issue, which further points to a network problem.
That said, I have yet to be able to really troubleshoot some more and will report back in some hours after my day today.
One thing right now though, to maybe procrastinate at work a lil , do you have a schematic or something of the osc messages/addresses to and from client to orac? I have been slowly working up some nodejs skills and wonder if I cant try and work on a browser osc client for orac using oscjs and this
I have a strange MIDI problem. I have a Keystep keyword connected to the Organelle and with orac 2 all midi-notes sorta stutter if I play fast or arpeggiated. Its like every new note abrubtly ends the previous. No such problem with “normal” patches or with orac 1. Same problem if the notes come from my Digitone. I’m running orac on 3.1 + PD 0.49 from internal SD-card. Nothing else has been modified.
Edit: side question, can you use the lemur settings file with TouchOSC editor?
there are two osc protocols
the one you see in the PD/Lemur clients I call ‘OSC display protocol’, this is just rendering a display to the patch - if you open up the PD patch you will see its trivial.
this is deliberate, since I wanted it to be write for another platform
e.g. people ask about android , but I dont have a android box to develop on , so the community could easily write this themselves
then there is the underlying protocol between Orac, which is a proper protocol that not only distributes data but also meta data, this is how the Push2 is implemented in MEC - so it can have a completely different look n feel.
this protocol is described basically here:
its out of date, but its basically the same idea - if you use oscdump of similar, the above doc will give enough idea to decode whats going on.
using what modules? how’s the cpu?
how do you have midi setup?
what channel are you using?
have you changed the active module?
do you have the midi on the chain on?
are you sending across multiple channels?
I really need more data…
(also if your not already try using midi channel 1 only)
EDIT: hmm, I think the issue is if you’re not using midi channel 1,
I suspect its treating it as MPE, so each channel ends up having only one voice, so its kind of monophonic. … I need to do some tests to confirm, but seems likely.
sorry - nope, completely different apps.
I’ve not used touchosc, so dont really know whats possible - but you could probably adapt the PD client to it… e.g. just look at the osc messages its getting, and setup the same in touchosc.
Thanks for the reply. I’m trying to figure to what’s up with my midi setup. I’m using the Organelle with a Digitone and the Keystep. They are all interconnected via an OpLab midi bridge. The Digitone’s 4 tracks use midi ch 1-4 and the Organelle midi system setup is using ch. 5, but its doesn’t seem to be relevant for how orac receives midi.
In orac I’m testing a simple setup with Rodey on A1, AnalogStyle on A2 and a bit of r.reverb on P2.
Chain 1 midi is “In Midi” off, “In Midi Ch” 1 and “Out Midi Ch” 0.
(Doesn’t seem to matter what I do here)
Main Ctrl. 1 is “Dest” 1, “Main Midi Ch” 1, “Note” on, “Ctrl” on.
(Setting Main Midi to fx 5 and orac goes monophonic)
Main Ctrl. 2 is “Prog” on, “Aux CC” 64, “FS CC” 0, “Exp CC” 0
When I set the Keystep and Orac to Ch 1 everything seems to work, but I can’t figure out how to set a Ch for individual modules. I’ll go back and watch your youtube intro again too see if I can figure this out.
You can download the Lemur Editor for free, and use that to reverse engineer the Lemur template without actually purchasing the Lemur app.
(I’m thinking about building an HTML interface to run on a web server, or perhaps on the pi itself, so I’ve already taken that step.)
At a glance, I think a TouchOSC template should be doable, but the protocol might have to change, to put text in the labels. Not sure - it’s been a while since I’ve used that.
First off, major thanks for this! :)))
I’ll update and bug fix my modules soon!
Then, a bug report @thetechnobear:
I encountered a strange situation when trying to run Orac 2.0 & TigerVNC!
TigerVNC works flawlessly, but I can’t start Orac2 anymore when TigerVNC is running!
It just won’t come up. Haven’t tested any other Organelle patches yet.
I am seeing the Organelle Desktop over VNC.
Thanks so so much for all these great tools!!
see this thread PureData 0.49 update
Q. when did you install the PD49 update? it should have been fixed yesterday. (afternoon?)
if you installed prior to that, either reinstall it, or follow my fix in the above thread.
(probably best to reinstall - so I know the fix is working )
personally, Id used the PD app as an example - its much clear to see that then Lemur template
you cannot set individual channels for modules - only for chains (see the original orac 1.0 video for that)
yes, the System->midi setting - only the midi device is used … channel , in / out settings are no longer used in Orac (as its has its own, more comprehensive midi options)
ch 5 = monophonic - yes, this is a bug!
ch 1 , currently is the only polyphonic channel 2-16 are all monophonic !
MPE users might guess why
anyway, the bug is fixed in development … I just have to push it out.
what Im currently doing, is trying to wait for a few more people to install and try it, and report any other issues, and then I will release an updated beta.
Thanks, I’ll wait for the next release.
In regards to all this Midi-stuff. What is the actual functionality of the Chain Midi page? As I understand I can make more chains and give them individual channels, yes? But why does my current chain 1 receive midi from my Keystep even with “In Midi” set to off?
What I want to do is to have one or more chains in orac and trigger them individually from the midi tracks on my Digitone, preferably with the use of the Digitones parameter locking different CC values.
That worked beautifully! One thing: I had to reinstall PD094 AND Orac2 for the TigerVNC to work!
But it works great.
I LOVE how the plops & tics from Orac1 are almost gone: it makes a very reliable instrument!
odd that you should have to reinstall orac… cannot think why that would be
oh, well main thing is its working!
and thank you for noticing
(theres quite a lot of subtle changes, that won’t even make an change list)
you can do all this already…
what your missing is there are two ways to get midi in!
chain input and ‘active input’ (also called Main Ctrl!)
active input, you usually associate with the organelle keys, but now Orac runs on other platform we need this possibility for midi as well.
(and as you’ve seen on my Orac 2.0 for Organelle video - I often use a ‘proper’ keyboard with the Organelle )
BUT as with many things in Orac, this is configurable!
if you don’t want to use midi for the active input, just go to the routers parameters
a) put main midi channel to something you dont want to use (e.g. 16)
b) set note to OFF
now you will get no midi thru the main/active input
(this is mentioned in the Orac 2.0 overview video … around 14:54 (https://www.youtube.com/watch?v=mywEOeth40Y&t=894s) … thanks to Antonio, there are timings in the YT description )
I should point out this idea of an active input, is pretty common,
electron have it (auto channel) and so do squarp … its often the default.
the reason is simple, not everyone has controllers that can send on different channels (or do it quickly),
so active/auto means the input is taken to a track that is ‘selected’ on the device.
(this is exactly what Orac is doing)
but for sure, if your driving with a sequencer its not that useful, so just turn if off, or move to a different channel
then simply change the chain midi parameters on
Chain 1 Midi In = ON, In midi ch = 1,
Chain 2 Midi In = ON, In midi ch = 2,
Chain 3 Midi In = ON, In midi ch = 3,
its be really useful if you tried this…
the idea behind the beta, is that I get to hear whats working , whats not, what can be improved…
if everyone just ‘waits for it to be finished’ , then nothing will get improved, since the only inputs is mine… and excluding bugs, I’m fairly happy with it as it is
Really incredible work! Enjoying it a lot so far.
The new routing structure is really intuitive and navigating the module menu and router makes the workflow much faster.
Looking forward to incorporating modulation and the sample management into my modules. It will also be great to be able to include example presets with modules.
I am finding modulation mapping a bit tricky, maybe I’m missing something though.
I’m finding it a bit error prone as there’s no easy way to tell what’s currently sending or the value, and I seem to keep ending up with unexpected mappings, or modulation sources modulating their own parameters etc.
I think this especially an issue with macros. It seems like since the learning happens when modulation is produced, and they only send when they are being tweaked, there is no way to map macros to other parameters of other modules because they end up being mapped to themselves or other parameters of the macro module (though you could use an LFO source on the same bus to do the mapping).
I think I’d prefer if you could explicitly pick which bus was being mapped when turning on mod learn. An ‘unlearn’ option so you could just tweak the param you want to clear all mappings if you don’t remember what it’s being modulated by would also be great!
A couple possible issues with specific modules:
- It seems like on brds/brds mono the transpose behaviour is reversed
- I can’t get any sound out of lmnts when playing with the keys (might be the settings, but I tried changing a bunch, and I can get sound with the default parameters in 1.0)
Anyway amazing work, hopefully I have time to try this with the RPI as well this weekend!
I’ll echo @WyrdAl, the modulation mapping isn’t very straightforward, and his suggestions for improvement seems good. I can’t wrap my head around how to unmap parameters, and manage to map modulators to themselves all the time.
Btw small bug: one of the voices in chordroll is stuck on one note. going into the pd sequencer subpatch and changing r croll-root-$1 to r croll-$1-root (same as the other voices) fixed it.
Thanks you for all your work, I need to try this soon!
Love that you have give it room to more graphic modules! I think it was the thing keeping me off from the first Orac
fixed both brds transpose ( I kept noticing this one, and promptly forgetting to fix it ) and chord roll
lmnts - works for me with the default settings?! (on both my organelles, and mac !?)
modulation learn - definitely more fiddly than id hoped…
as you have kind of spotted, the main thing is, unlike midi learn, you really have to turn off mod learn between new mod assignments.
mod learn on
macro 1 to 100% , go change one or more parameters,
mod learn off
sel macro 1 to 0%
mod learn on
macro 2 to 100% , go change one or more parameters,
mod learn off
actually with macros you don’t need to change amount to 100% but you do for lfo.
i’ll admit , I usually use LFOs to learn , with an amount of 10%, and offset of 50%
(so its in the middle)
I could easily stop the ‘self modulation’ as frankly that is not that useful, though its nigh impossible with storing much more info, for me to stop you doing this via feedback looks e.g. m1 -> m2 -> m1 … but thats not as likely…
so yeah, its fiddly as you have to mess with turning off other modulation, and just like midi learn, its easy to forget to turn of learn.
(unfortunately turning it off automatically, stops you quickly assigning to many things, hence why it behaves as it does)
(its a bit easier on a modular with cv, as there you have a knob to twist like midi learn, so its pretty similar to midi learn!)
I dunno, Im loathed to change to mod assignment
its not really the selection of the bus thats the issue - its the selection of the parameter.
(I dont want the user to have to start scrolling thru a list of parameters in every module, thats horrible)
i could do it off the last parameter still,
e.g. you twist a parameter to select, then go to the menu, into ‘mod assign’, then select with the encoder the mod bus (I do not re-use pots in the menus, they are strictly for param values!)
but thats still pretty fiddly
also the similarity with midi learn, means one less thing to confuse users.
(I get alot of questions already, so I dont want to keep adding new ‘concepts’)
a couple of things to note:
- if you remove/replace a module - its mod assignments are removed
- if you remove a mod source , its assigned are NOT removed.
(so you can switch from a macro to an lfo or vice versa)
- if you put a mod value to zero when assigning to a parameter it will remove that mapping (like midi learn)
so yeah, I’ve been thinking about how to improve both midi learn and mod learn for a while, but I just dont really like the alternatives much… and its pretty tricky with such a limited UI gestures available.