The orac God himself. thanks for the reply, but I ended up formatting the sd card before i got your reply.
everything works like charm again, but a little to late for that. wish i had them tho
The module basically just hooks up the external to ORAC parameters, but it has an internal envelope generator already so it works as a standalone monophonic voice.
I think for those not following this thread, its quite difficult to see new modules, and Im also getting PMs and seeing questions on forums about where to get additional orac 2 modules, and I suspect some users are missing out on your wonderful modules.
of course, totally your choice - I know from personal experience uploading things to other platforms can be a bit time consuming.
i agree there are plenty of good modules here and there, they are like pokemons
i believe people (including myself) are shy to publish in the Orac category of Patchstorage because Orac is multiplatform, i guess an Orac module for Organelle doesn’t work for Eurorack ? i saw a lot of Orac modules into the Organelle category… it’s ok but it would be better to have every modules in one page…
The original orac modules are cross platform - it’s only when you start adding graphics they become non-portable.
However, I think as long as you say it’s for the organelle in the description that’s cool.
It also means someone on another platform might port it to their platform. Which would be cool.
I thought about adding a graphics api to orac/kontrol but thinks like screen resolution/coloures quickly mean it would still likely not be portable.
This is why I’ve recommended things are underlying using parameters and then graphics are a representation of this - this is how vsts/au get around the situation and is why you can automate things!
That’s not to say I have anything against graphics , I don’t - they make things look more appealing - but they have some limitations if they are not backed by parameters
Yeah, I used to follow the Orac platform on patchstorage to look for new modules, but stopped after a while, as the only thing there are/were Mark’s stuff - it would be great if other module authors started publishing under it. Maybe use tags (and make it clear in the description/docs) to flag something as Organelle-only?
i think i understand… by “graphics” you mean anything that is coming from the patch, not coming thru the module.json parameters, right ?
i wish you could find a way so modules would work anyway by bypassing graphic messages automatically depending platforms (not for me because i’m happy with the Organelle but for Qubit Nebulae users i guess…)
an organelle-only tag would be cool, but also as discussed below… really many modules can be written so they are platform independent (where the graphics are optional)
they will IF you use parameters as the underlying control mechanism…
but I think im having a hard time explaining what this means
let me give you an example…
imagine a tape playback module.
so you want a graphical display which displays a pretty tape machine (say like the op-1)
it has a few controls
pot 1 the start point of loop
pot 2 the end point of loop
pot 3 tone control ( which maps onto lets say a filter and also add a bit noise)
k, so to make this what I would do is:
page 1 = graphics page (so no parameters)
and it has nice fancy graphics showing the tape machine playing, and graphically the start and end point of the loop, and say a graphical knob for the tone control
BUT the way the patch is implemented is:
module.json has parameters defined for: start pos , end pos, filter cutoff , noise amt
so the graphics page updates these parameters, then the ‘sound engine’ (the guts of the patch) works off the same parameters - as if this didn’t have any graphics.
what we are doing here is abstracting the visual representation, graphics, from the sound part - a very common software practice!
note: here how the visual representation of tone , is a 1 graphics control maps to many (2) parameters, this is fine … it doesn’t matter, that is possible if you want it. (or you could have a single tone parameter - up to you) - the point is the visual representation can be different to the underlying implementation.
how does this ‘help’?
a) if orac determines sees that there is a graphics page, and its not on the organelle it can revert to the underlying parameters , and the users still retains FULL control of the module!
b) save/load presets , and things like modulation matrix will work without any effort by patch developer since module is still using parameters.
as I said already this is exactly how VSTs (and AU) work…
under the covers VSTs expose parameters - and this is what DAWs work with to allow thing like automation to work (you can see this on almost any daw if you look closely)
the VST graphical screen you see, then is just ‘rendering’ these parameters.
have you ever seen VSTs where you have something on its GUI where you cannot automate it?
I think we all have… often(*) , this is because the developer has ‘got it wrong’, they have basically not though… they developed the UI, and just tried to bolt on parameters later.
(*) there are some cases where this is valid, e.g. if automating a parameter is too processor intensive to be useful for an end users as it would create audio artefacts.
so really this is an area where its about how developers design the patch…
of course, I can improve Orac in this area (and others) and potentially allowing rendering on other platforms, but that can never be perfect due to hardware limitations, so we need to have a ‘fall back’ to a lowest common denominator.
one last thought, Ive been thinking about (mid term) pushing the Organelle UI over into a separate process (MEC), for improved performance, so that PD can largely concentrate on the sound.
this would mean Id potentially replicate the graphics api into MEC for other UI devices, though it’d only be for some devices… e.g. it not makes sense (at this point ) to have graphics on a remote web front end.
I do intend to put these on patchstorage
I put them up here to flush out any issues before a wider release. This seems to keep getting delayed in favor of making new modules (which might be a side-effect of modules being so easy to make!)
Most of these I consider stable now though so I’ll start putting them on patch storage this week.
Many thanks @thetechnobear for taking the time to explain deeply… i’m spending more time learning about modules than patches at the moment so i’ll have the basics soon i get the thing about the benefits from using parameters (also from not using them sometimes), i still don’t get one fundamental thing but i’m working on it :
i’d like to use parameters without printing them on screen the way it automatically does, or in other words, i’m looking for a way to avoid sending on screen the module.json parameters, to only use them in the patch and send custom graphics from it instead, i don’t know how to do this yet…
because actually i’m able to run graphics on modules but without using parameters, i improvised by bypassing the .json file (i’m calling [r oknob$] in the module and use some [spigot] so they are active only when the module page is active), it works but it feels like a temporary workaround…
I don’t think it’s that clear cut, unfortunately - this weeked I added multicycle to orac on my PiSound, as it’s my preferred clock on the Organelle. I quickly found out that without the visuals to tell me which slot I’m working on, I can’t use it. Arguably this could be down to “practice practice practice”, but when done properly the visual feedback is invaluable, so figuring out what is and isn’t “compatible” might not be as easy as it would seem.
P.S. Actually I’ve realised there might not be a solution for this, as some people will probably be perfectly happy using this sort of modules (and maybe I would too if I had never used the visual version
Hi all - a quick one here. When I have an fx (say reverb) in B1, and a synth in A1, is there any reason that there might be a tiny bit of signal leak between the chains? I have chain two In R Gain up to 100% (to work as an aux fx from my mixer) and am hearing a very faint reverb on Basic Mono from A1.
Here is what I did. Maybe this helps troubleshooting…
I Load Orac -Add Modules -Press the Encoder - Scroll to the Second (Empty Line) - New Page opens up- 'New Preset → New-0 is created - (Add Modules) - Safe Preset
I also tried to Add another new Preset (New-1) but I cannot go back to New-0 and when I reopen Orac all the presets are gone.
) to have graphics on a remote web front end.
i get the thing about the benefits from using parameters (also from not using them sometimes), i still don’t get one fundamental thing but i’m working on it :