Or another module. I powered it with polybeats and it created a really cool pattern morphing effect to the chord changes!
it’s weird. I downloaded again, deleted the old chorder from my USB and installed the new one but it isn’t waiting for the note input to advance. As soon as it loads up it just starts playing rather than waiting for me to start polybeats. other things like all the synths wait to get triggered by polybeats.
I’m trying: polybeats ----> chorder ----> polysynth
am I missing something?
gah! now I see that there is an option on the screen to allow it to accept the notes! thanks! it’s amazing now!
a question that i think is primarily aimed at developers…
(tldr, summary : this is probably going to happen in next few hours, so this is really just a ‘sanity’ check to see if ive missed something obvious)
so for Orac 1.1 Im considering two changes , one which requires a small update to modules, and wonder what your thoughts are?
the changes are related and are to do with , how audio is passed between modules , and where the gain control is applied.
what we currently have in a module looks something like this:
ok, so obviously a module need input (might be an fx) and output.
but you’ll notice how the module also passes thru the audio
I did this because many fx modules have a ‘mix’ value, so by definition they do pass thru the audio.
(albeit not like in the diagram)
however, now I think this is a mistake,
gain control / audio thru in modules
orac (in the routers) can only adjust gain of the module from its total output,
i.e. input pass thru + ‘synth’ output
but I think users would prefer the module gain to be the of actually module output , not the combined output
e.g. imaging, we have in a chain (which says is used for layering)
mono synth (m1) -> mono synth (m2) ->out
adjusting the gain on m2, is the sum of its input and mono synth, so you cannot really just the gain on the second mono synth
so the intention is…
to change it so modules look like this:
then the router module will allow:
- pass thru gain
- module gain.
(passthru gain, in theory this could just be on/off as you can control the gain on the proceeding module, however, it may be you want to run the output of that module ‘hotter’ into the next module, but only want a smaller amount of that to then be passed thru the audio chain)
technically what this means is…
audio pass thru (and panning/gain) comes under the control of router, rather then individual module. this I think is much more flexible.
(and if later i decide, not 1.1!, to add a special UI controls for the router modules, then this is pretty much essential… e.g. consider something like a ‘central mixer’)
dont pass audio thru in the modules
- you don’t really need any gain on input or output in the module itself , as you can do this in the router.
its the first which is kind of a breaking change, as the second just means you have something in the module you dont need.
the first means, if the module is not updated, you get duplicate audio thru (I will of course update all ‘factory modules’) - however, the user has a work around, they can set the passthru gain to 0 for that module, which they might also want to do where a module has a mix.
one possibility (likely) is for me to default passthru gain to 0, to help alleviate the issue.
this is ok, since for most ‘simple cases’ , audio pass thru is not needed ,
this probably is ok, since the synth does not need it, and fx1/2 probably have a ‘mix’ control anyway.
where its usually going to be needed is if you layering synths on a single chain, of your fx modules dont have mix.
doing this means , module writes still should change their modules for consistency but its going to be less problematic if they take a while.
note: setting audio passthru = 0 by default, is also probably consistent with the audio input to 0
(though amusingly, if passthru = 0, then I can actually change the audio in default to 1.0, as the passthru will stop the ‘bleed’ noise anyway!)
(note: Orac 1.1 will need users to ‘reinstall’ 3rd party modules… but they can use 1.0 modules without issues)
I think to avoid too much overhead , I think we should do this on a ‘per chain’ level… not individual modules
(thoughts? its not a big overhead, but nothing is for free in code )
sounds like a change for the best and not too troublesome while patchstorage is still yet to be flooded with modules
yeah no problem - makes a lot of sense (I’ve got some modules coming but have become distracted by another project - will be returning to orac sooner or later however! )
Was just away to ask this.
This seems like a good idea.
Please smooth the mixer so there is less zippering.
That make sense, adjusting module gain could be a bit tricky when it affected everything everything earlier in the chain. I’ve been adding a ‘volume’ parameters to my synth modules so you didn’t need to go to the router to change the volume independently. I’ll probably keep the volume control on synths and mix controls on FX as I think its useful to be able to adjust those as you tweak other stuff without needing to navigate to the mixer.
I actually do stack/layer synths (or other audio stuff) in a single chain quite a bit so I’d need to get used to adjusting the passthru gain after instantiating those. In my ideal use case you could have an optional attribute in the json that specifies the default pass-through behaviour for the module (probably just on or off, could default to leave the old value if unspecified). Maybe the router wouldn’t be obliged to obey it but you’ll get the desired behavior when a module loads without needing to go to the router.
Anyways overall this change sound good to me!
already done, I use the same approach as the main volume, so now uses a sqr scale (finer control) and put it thru a sig~ and lop~ , so now no issues.
(this is done for all gains in/out and thru)
I’ll be doing the same for pan
I cant do that currently… as the modules knows nothing of the router… and the router knows nothing of the module!
I think really the core issue, is making the router UI a bit more friendly/accessible…
Im not going to mess with a dedicated UI for this release.
but I can say that the new structure is much more logical, as you get a patch for each module, and a page for each chain in/out… so it makes more sense.
Ive done for the R-1x10 router, and updated the subpatches it uses, and the router patch is now much more easier to understand too… so thats cool, will make it easier to add new routing topologies too.
I just need to do the other routers, and check they are ok, but pretty sure they will be fine.
note thru is also getting a bit of a tweak too, so its in line with audio
looks like passthru will default to 100%, and notethru to true.
most of these defaults will be fine, and the user will just now tweak the gain levels of the modules.
(tweaking passthru really only comes into play when you need to mess with the input gain for an fx if it doesnt have it itself)
current idea with panning…
there will be a panning on both the input and output.
( what i want to do is take a stereo input, and re-pan it to a new stereo output … not quite sure on the control of that but I’ll work it out )
output is obviously so different chains can be spread out over a stereo field.
input im thinking is more like a ‘filter’ , so you can send the left input down one (or more) chain, and the right down another i.e. use the stereo input as 2 mono channels… thats my thinking currently at least.
but being a pan, you can also send partial mixes downs different chains!
again the trick is, whilst i want the input mixed, I think I then would prefer it spread across the stereo field on the input chain… not sure if i can do this with one control though!? (as theres quite a few different use-cases)
ok, i think to keep things simple, and flexible, what im going to do is:
output : split stereo panning
this allows the user to move the stereo field fully
input: individual l/r gain , followed by split stereo pan
so you can filter out either side ( by a variable amount and/or boost ), and then reposition it for the subsequent processing.
(this allow the common use-case of taking one channel, then shifting it to the centre, much like how you would do on mono channels on mixer)
… takes 4 controls, which plus midi , means 2 pages for chain in… but, i cant really think of a better way at the moment, which uses less controls, and similar flexibility.
Is there a way to know the difference between notes from other modules and notes coming from the keyboard when the module is selected? The idea is so the keyboard can be used as a control for a module, without notes in the chain triggering those controls. basically an incoming notes receive that is only on when the module is selected.
the issue with doing this kind of thing, is it complicates the ‘normal use case’.
since it implies modules would have to take the note input AND the keyboard input.
(the keyboard input is already a little complex since its the active module)
that said… it is possible for an individual user to change this behaviour, as this functionality (active module getting keyboard input) is actually held in the router module, so different router modules could have different functionality.
I’ll think about it, its a tricky one, I can see for the odd module it being useful, but for the majority of modules it seems like a complication.
also there is an interesting design question here:
the keyboard already is not always used by as notes, it can be used for other functionality, and it can be fun sequencing this… despite the fact they are not notes!
… so splitting this functionality would actually be limiting.
(so your request would essentially stop this… which is not nice)
also be aware the router modules already have the ability to not pass thru notes not to the next module, this is under user control, so its the user that decides if this is what they want rather than the module designer.
anyway, as i said will muse on it for a bit…
thinking about this notesIn / keyboard routing
what about just adding a ‘keyboard direct in’ message going to the active module. so everything stays the same, just an added message sending key presses directly from keyboard. then the module can decide which one to use, standard notesIn or direct keyboard if it really needs it?
agreed that most of the time allowing notes thru the chain is desirable and most flexible. and being able to disable the notes thru in the router is great. but there are some cases where you might only want internal keyboard to control functions, and having upstream modules controlling those functions would be confusing.
for example something like a multi track recorder module. the keys might be used to record enable tracks, or select songs or something like that, functions you would never want to drive with an arpeggiator.
but I do like how with the current design the modules are just MIDI and audio processors, and this introduces specific hardware to module api which is not as elegant… so maybe there is a more ‘generic’ way to achieve this idea.
definitely worth musing over
yeah, i also like its not prescriptive , e.g. who am I to say you don’t want an arp to trigger your multitrack recorder
however, i am currently in the process of thinking about routing a bit more …
Ive added split stereo for audio, but thinking of reviewing this again…
(simply put, many things are mono, so im wondering if there is a way to split things up between mono and stereo signals… cleverly - but early days on that)
ok, so theres two things that I need to review on this.
a) modulation ‘types’
being more flexible with modulation signals, so far we have notes, fs, aux, I want to allow for more
b) multi channel / concept of voices
this is a bit difficult to explain, but for MPE we want each midi channel to be a separate voice.
whats interesting though, is we also kind of want something similar for polyphony…
basically the poly object gives us a voice index, rather like we have with mpe.
its this latter, point that might be interesting for the internal keyboard, perhaps it could either be on a separate channel?! (but ive not though this through fully yet )
the thing about the above its all a bit more elaborate, so I need to not only find a way to implement it, but also to not make it harder for end-users… which is always the tricky bit.
I think the thing is, Ive taken a bit of a break from orac, (after doing an initial burst of dev, which covered much of whats was required for 1.1), and its been useful to have a time to reflect a bit, to think about whats good, whats bad, and how i can improve things - so thats kind of delayed 1.1 a bit, but in the end it will (I think/hope) be much better for it.
can anyone offer some help? i’m getting to grips with module making a bit more now and have started working on a new synth which is taking on some shape.
simultaneously, i’m trying to add lfo’s to the controls of a lot of modules i like. I know modulation modules are planned for orac but this is a learning excercise for me.
I’ve used mooglfo as a basis and have it working on some parameters for other modules - but now Im having trouble getting an lfo working on clds
Anyone know why? Is is a control/signal issue? Any help appreciated.
looks like it, you have a signal going into a message box.
an easy thing to do is convert the signal back into discrete control messages using [snapshot~]. you want to bang the snapshot (using [metro]) to capture the value. probably set metro to something like 5ms
Fantastic! Thank you owen - having a blast with orac at the moment.
F-clds .zip (101.2 KB)
Here is my modified version of @thetechnobear 's great clds module - with pages added for lfo modulation of Size, Position and Density. I also switched the pitch value for frequency so it’s less steppy - just personal taste i guess. If anyone has suggestions or notices any mistakes in the patch please let me know, it would be really helpful to me. This one you just drag and drop into your modules folder as I haven’t figured out the .zop method yet. It’s probably simple, just haven’t got around to it yet. Anyway, Elements is next
previously posted in wrong topic:
@chrisk @oweno @thetechnobear I’m trying to mod the ‘sampler24’ module at the moment, do you know where in the patch I need to look to add a toggle on/off for looping?
@Wannop have you had a look at how the Loop Jam Rec patch handles looping?
I’ll have a look see!