Orac : module developers guide

[thetechnobear]

This thread is for discussion about developing modules for Orac.

When I created my first patches for the Organelle, I found I spent a frustrating amount of time patching the UI,
and then still lacked featurs I thought end users would ‘expect’ , such as midi control, preset loading/saving.

This really was the starting point for Orac…
I wanted something I could create modules for quickly, without having to worry about the UI, just concentrate on the module functionality,
and get things midi, presets all for free, and I wanted this ‘support’ almost invisible to the module, so you dont have to worry about complex apis etc.

Having now written/converted over 50 modules for Orac, I personally feel Ive achived this, I hope you will too.

Here is a video, which walks you through how to create a module,

p.s. as an example, a few of the C&G patches I converted in about 10 minutes

and a video on how to convert existing organelle patches (in this case Nori Sampler)

Why write a module rather than a standalone patch?

• its quicker
• is musicians get to use your patch in interesting ways, by combining it with other patches
• you can focus on the core functionality, get midi learn, presets, remote control (via osc), cross platform - for free

What is a module?

well it can be anything, including a complete patch.
but the best module (imo) are ones which are focused, e.g. a synth module doesnt need to include a reverb, since the user can include a reverb of their choosing. so if you have a unique sequencer, fx, synth release as separate modules.
not a cpu hog, ok reality is some modules are going to be hungry for CPU, and thats ok… but just be aware if you use 90% cpu, the user is not going to be able to add many other modules. (another reason to split things up)

Distribution of modules

so basically to use a new module, all you need to do is drop it in the Modules directory … so you can release on Patch Storage

in v1.0 be aware re-installing/upgrading Orac will remove custom modueles… Im going to change this in v1.1

Another possibility, will be to include in the ‘factory’ modules for future release,
though they will need to meet a few criteria (e.g. open source, maintainable), we can discuss this later.

Module installation

ok, so to install nicely the best option is to use the organelle installer package
(this is particularly important for modules with large/more files, since it correctly checks that files are not corrupted)

to do this, we first need a deploy script in the module directory, this is very simple
its called deploy.sh, and can contain as little as:

oscsend localhost 4001 /oled/aux/line/2 s "installing"
oscsend localhost 4001 /oled/aux/line/3 s "orac module"
cd ..
mv $1 orac/modules
exit 1

then on the organelle we need to create the zop file, we so this in the modules directory (so above your module directory, so for S-norisample we use

~/scripts/create_install_package.sh S-norisampler 

it will report something like

[root@organelle2 modules]# ~/scripts/create_install_package.sh S-norisampler 
create install package for S-norisampler
move existing manifest away
  adding: S-norisampler/LICENSE.txt (deflated 49%)
  adding: S-norisampler/deploy.sh (deflated 38%)
  adding: S-norisampler/manifest.txt (deflated 40%)
  adding: S-norisampler/module.json (deflated 53%)
  adding: S-norisampler/module.pd (deflated 68%)
  adding: S-norisampler/samplervoice.pd (deflated 66%)
  adding: S-norisampler/sound.wav (deflated 24%)

this will create the file S-norisampler.zop which is what we ‘ship’

for user they then just put this in the same directory as orac (not in the modules directory!), so for most this will be /usbdrive/Patches.
(the reason for this is placing in the orac or modules directory would mean you cannot see it in the Organelle menu to be able to see it)

you can find the S-norisampler example on PatchStorage here
https://patchstorage.com/s-norisampler-orac/

[healthylives]

Can I ask a dumb question? How are you editing on your mac and previewing changes live on the organelle?

[thetechnobear]

he, he - not a dumb question at all - its magic

no, I use another project of mine called ‘OscProxy’

its two parts running over wifi

• one part runs on the Organelle and sends all the knobs/encoders/keys to the Mac
• another part runs on the Mac, which sends all the screen messages etc to the Organelle.

so actually the PD patch is running on the mac, but all the interaction is done on the Organelle…

I do this for the video, because I can then screen capture the mac (which I dont have for the Organelle)

I need to put out a new release of OscProxy as the last one is a bit difficult to setup… more a personal dev tool, but Ive an idea how to make it simpler - now all i need is time

[shreeswifty]

i just saw this
i will try to drop the ZOIA clone project into this i assume
it’s supposed to be minimal quick and i think they would fit nicely

I’ll take a crack at adding them to this because turning them all into standalone patches does not sound fun, so this should be way nicer

[Lazaruz4]

So brutal!

[wo3]

Is there a list of available value types?
How does the scaling work? I would like to use percentages, but with maximum resolution instead of stepped. This may be standard functionality, but don’t have a chance to check for a bit.

Also interested in a way to work in GFX overrides so that there will be more flexibility with the screen. Probably further along.

Looks fun!

[ghostly606]

The scaling / resolution is only for the screen, the user still defines the resolution of the audio engine.

+1 for value types.

[thetechnobear]

types are (off top of my head ) - pct, time, pitch, freq(or is it hz?) , int, bool
all can have defaults
all except bool, can have any range they want

i will be adding more types, and im thinking about custom display.
(however, please note… ive very particular design goals in this area related to remote control/displays., more on this later)

resolution - display rounds, but there is no stepping (currently, it could be added)
the stepping you see, is actually the pot resolution (or more specifically, how Organelle rounds before sending over serial and osc), so its the highest it can be.

(orac uses 32 bit floats, so for example when using a push 2 as a control surface, the resolution is much higher)

yeah, please ‘bare with me’… i know from Kontrol about requirements for things like enums, but the priority then was Orac (which really is the ‘product’ of kontrol).

#1 priority now, is to support new users, and also module patch developers, to get Orac in use.

#2 priority is probably the web app, so Orac can be controlled from an iPad/iPhone, but hoping (and got some interest) others might help on this.

after that, more features for Kontrol, is probably the thing most needed.

so lots on my plate…

if there are any developers interesting in helping, this is open source, so contributions are most wanted.
mostly at the moment this is in the C++ field, and web development,

also all users can help, by fielding questions from others, helping build the community around orac - this would be really awesome.

[keymanpal]

I’m here for the last part of your post ;-)…

[wo3]

Can I use floats as default values and min / max values in the .json files?

[thetechnobear]

Thanks @keymanpal much appreciated

@wo3, yes ( If understand correctly),
oh float is also a type , but i don’t use as it has no units.
generally , if you have a look at the modules there are examples of all types in use.

[ghostly606]

+1 for fielding questions if I can. Also trying to spread the message on other forums where appropriate.

I really think adding modulation busses would open up the Organelle further, so really looking forward to what you come up with here. All in good time I hope.

[keymanpal]

Ahah always that little extra, something more yeah but I’m guilty here also

[ghostly606]

Haha, it was @thetechnobear who raised the prospect, has got me salivating!

[Generationloss]

Trying U-clock > Arper > Analog mono. Isnt behaving how I’d expect when I alter bpm in U-clock. Can anyone shed some light on what/why it’s not like changing the bpm on a regular Arpeggiator? Have I missed something out that’s needed in another module/settings?
Thanks

Edit - wrong thread… Mods feel free to move to the other one. Thank.

[Generationloss]

Is there a module that has a volume level boost param lurking in it? Finding some of the synth levels hard to balance how I’d like them when layering.
Thanks

Edit - wrong thread… Mods feel free to move to the other one. Thank.

[keymanpal]

The routing modules has all Gain control over each individual module.

[Generationloss]

Cool, thanks!

[Wannop]

Gain staging is controllable for each module in the routing module (e.g. 1x10 ect), just scroll encoder to the page for the module you wish to boost. You can also edit midi note thru for each module here.
Edit: Whoops, too late!

[keymanpal]

@Generationloss

it’s not like changing the bpm on a regular Arpeggiator

Are you sure you’re only using one U-clock?

[aus10]

This is a really promising idea. If individual organelle patches are bricks, then orac is the first machine to automatically stack bricks and cement them together! Very exciting.

I have a question - do the routers send the midi notes out as well? From what I see in subpatches/connectout, it should. But if I put in U-rhythmicon without any following modules, and connect a separate physical synth via midi cable, it doesn’t trigger the synth like the Stereo Rhythmicon patch.

I’m new to pd but I’m happy to pull together a PR on github if you point me in the right direction and there’s anything I can contribute!

[thetechnobear]

it should be sending out midi, i can double check.

have you set the output channel on the router?

edit: hmm, i need to double check 1x10… the others i put the channel on the end of the chain, but 1x10 is one long chain, perhaps i forgot to add, if so i will add…but you can use one of the others for now if that’s the case.

[thetechnobear]

ok, just tested all is working as expected. (including on 1x10)

so I assume you just havent set out midi ch, on the router.

[wo3]

Currently finished dust fx module as well as a synth bass drum.

I really don’t like the heavy usage of the encoder pushbutton, but I don’t really see another way to have so much functionality.

One thing for other devs is you need to use [r loadbang-$1] instead if loadbang. This gets kind of weird when using abstractions.

[thetechnobear]

@wo3

One thing for other devs is you need to use [r loadbang-$1] instead if loadbang. This gets kind of weird when using abstractions.

yeah , not sure if I mentioned this in the first video…
but Id did in the new ‘converting patches to modules’ video.
this is a quirk of PD, loadbang only gets called when a main patch is loaded, not if you add a subpatch… most pd programmers know this, as when your developing you tend to have to chuck in a bang ui to do what will usually be done automatic

yeah the $1 you have to watch, I do mention this in the second video, it just means first parameter which happens to be module slot in orac, but as soon as you start converting things with other parameters this wont be the case (assuming you do what I do and tag it on to the end of existing parameters)

one important thing to watch for here is default parameters, as you need to pass in the module slot, if you tag it onto the end, then you have to also add any intermediate defaulted parameters…

again, this is nothing new to experienced PD programmers, as they are used to adding parameters, but if you are ‘blindly’ converting patches its easy to catch you out.

@wo3

I really don’t like the heavy usage of the encoder pushbutton, but I don’t really see another way to have so much functionality.

Im all for constructive criticism/feedback, if you have an alternative im all ears.
but unfortunately the Organelle has limited hardware ,using the pots for non-parameters is really confusing, and the keys are unlabelled… and i dislike patches that start saying ‘C#3 = func1’ ‘D3= func2’ … its really hard for users … I do it, out of necessity in OTC, but its horrible, so was not going to do that in Orac.
I cant use Fs as not all users have them, or want to use when casually using the Organelle (e.g on the sofa)

of course, the idea is for performance use, you use midi learn … and Im thinking I will look to extend this a bit, eg. either program or bank changes for presets changing… and perhaps allow mapping of other functions (switch module, midi learn) to external controllers - but again for casual use thats not feasible, so cannot be a primary access…

for other platforms this will be different… and also the idea (as ive detailed) is to add a mobile web app, so users could use that (or push2)

but as i said, if you have any ideas on improving id love to hear them

[andy]

@thetechnobear

and a video on how to convert existing organelle patches (in this case Nori Sampler)

will it be on patchstorage so we can add it to the collection?

[thetechnobear]

Yeah, I guess so… I need to sort out a deploy script, so that I can show module developers how to make it easy for users to add modules.
(Basically it’ll be an standard ‘install zop’ option.

It will also be in the Orac 1.1 release but that’s going to be a while yet.

[shreeswifty]

hey @thetechnobear i made two modules i think that satisfy the requirements

gendyflext.zip

Dropbox - Link not found

can you maybe take a gander at them and tell me if they are completely wrong or just missing something?
I built them with MEC/ktrl and the monorack but maybe that is not enough?
or maybe i am just trying too soon. The first one is an ‘S’ module [stocahstic sound maker] and is quite simple and straightforward

cheers~

pp

[thetechnobear]

did you follow the videos i made? do they work ?

Im not quite sure what you mean by ‘requirements’,
Ive merely explained how to get things to work, and what I think makes a good module.
The rest is up to you, and the people who use your modules… its certainly not for me to judge modules etc.

If you say they are working within Orac, then I’ll see if I can find time look, but no promises as Im really busy at the moment…

if there not, then please check the videos… they took a long time to do, the ‘conversion video’ might not look like much, but probably took me 2-3 hours, by the time, id setup, captured the video, messed about editing (zooming screenshots) , and then faffing about with my crummy internet connection.
then if something is not working as expected, let me know what you think the problem is, or whats seems to be wrong.

[shreeswifty]

they are not showing up in the orac system so i thought you could offer some reason as to why
i watched the video and i think i grokked it but perhaps its a naming thing

[shreeswifty]

i think i found out what’s going on

pp

[thetechnobear]

added to top posts, notes on how to create an installer for modules

[ghostly606]

@thetechnobear

ok, so to install nicely the best option is to use the organelle installer package

Sorry Mark, not your fault obviously that I am a bit of a computer coding noob but this is like a foreign language to me!

Any chance of a quick video?

[shreeswifty]

thanks for the installer into i think i made an assumption with the MEC/Ktrl json then i changed some things but i am going to wait on other ones and just release regular patches for a bit longer. and make a few from scratch instead of trying to convert existing ones

cheers~
pp

[thetechnobear]

probably not… i really don’t have the time to do more videos at the moment, this is seriously taking a huge amount of time for me…

and its really is simple

just add the contents I posted above to a file called deploy.sh, then run the script I detailed

so lets say your doing S-norisampler, and you have it in
/usbdrive/Patches/orac/modules/S-norisampler
so you create the file
/usbdrive/Patches/orac/modules/S-norisampler/deploy.sh
(add the contents above to it)

then you type on the organelle

cd /usbdrive/Patches/orac/modules
~/scripts/create_install_package.sh S-norisampler 

then copy the file created which is S-norisampler.zop to patchstorage, or wherever…

perhaps if this is enough to get someone else to do it, and then they can make a video and ‘spread the load’ a bit.

[ghostly606]

That makes more sense, I’ll have a go at that, thanks!

[bomboy]

Hey @thetechnobear I had a quick question. And just want to make sure I understand this correctly.

Say I convert the Vocoder and Ivertide patch into modules, and I’m running Orac with the 2x4+2.
Does that mean it will run an audio signal into two different paths? Do they operate independently,
so the audio signal would look something like this?

Or does the first set run directly into the second?

[thetechnobear]

go watch my video (it has pictures of all the routers)

2x4+2 mean 2 chains for 4, followed by 2 after the chain… so the chains are independent, and then converge for the final two modules…
hint: remember you can put the router/clock where you like, and they just act as passthrus.

[bomboy]

That’s all I needed to know! My thinking with this is, I could take previously made patches and actually put them together to make the Messina Machine all in the Organelle. Which is wild to to think about! I’m getting crazy pumped just thinking about it.

[ghostly606]

Is it possible to assign a MIDI message to the Aux in Orac?

[keymanpal]

MIDI CC25 is still there no need to map ít… don’t know if intended this way; could be fun/creative, to be able to map it freely. @thetechnobear what is your opinion?

[thetechnobear]

yeah, I think the original CC mapping are still there, though not checked…

though Im thinking perhaps the CC for the knobs at least should be removed, as cant see their use makes much sense… as you need to know what page your on, then you might as well use the organelle or even better midi learn

as for external control, yeah, perhaps thinking about other mappings to functions is a useful thing, especially should program change be used for presets?

also, bare in mind Orac also supports an a whole range of (unpublished ;)) OSC messages, which so everything from midi assignment, preset loading, parameter change - in fact everything, as this is how ‘remote control’ for things like the Push2 work.

[keymanpal]

@thetechnobear

as for external control

Thanks for insights; yeah difficult choices…

OSC, I think is the way forward for using an Ipad/Lemur, having access to many parameters and yes remote;-)

[WyrdAl]

Just tried out making a submodule, its the chord generation logic from muchord.

I also made a couple variations of variations of other modules I found useful:
punchyl is punchy but the period is up to 64 steps, so you can get much slower changing notes (especially useful to control muchord or another punchy running at a faster rate)

arperopt and gennyopt are modified versions of arper and genny
They both maintain a sorted table of notes currently being held,
which was resorted every time a note changes. With muchord when a new 4 note chord is played it would do the sorting 4 times (and there are another four if the last chord is turned off at the same time) which can cause audio dropouts. These versions wait 5ms after the notes are stable so the sorting will only happen once.

I did have some issues using create_install_package.sh though, when I ran it I got the error message:
mv: failed to preserve ownership for ‘U-muchord//manifest.txt’: Operation not permitted
And the zop wasnt created.
I think because it tries to ‘mv’ the files between the usb drive and the organelle filesystem.
I just manually zipped it into the zop so there is no integrity checking on these but they are quite small.
If anyone want to try them out you can grab them here:

adbrant/OrganellePatches

Just put them into the folder you have orac in and select install.

[thetechnobear]

@WyrdAl

mv: failed to preserve ownership for ‘U-muchord//manifest.txt’: Operation not permitted
And the zop wasnt created.
I think because it tries to ‘mv’ the files between the usb drive and the organelle filesystem.

No it won’t be filesystems, as I do mine from two different mounts too, it’s probabky because the usbstick is fat32 , whereas I use ext4 on another sdcard partition.
I’ll have a look, I don’t want users getting confused by two different install procedures - and we are seeing lots of failures on usb sticks (esp the white original) , so verification is really important.

Edit: ah I think your saying you still had the files then just zipped it? Did it have the manifest as well? If so , then it’s still a zop, just by a different means

Punchy I thought I’d alreadyextended it to 64 steps, have you changed the time divisions?

How did you find creating the modules, did my videos miss any steps?

[WyrdAl]

I found making the module pretty straightforward! I don’t think the videos missed anything. This was a pretty simple module though, I’ll see if I hit anything on a more complex one.

Edit: ah I think your saying you still had the files then just zipped it? Did it have the manifest as well? If so , then it’s still a zop, just by a different mean

There are no manifests in those, the script did create it but was giving me an error on installation so I took it out. Just tried it again and it worked, could have been because an old manifest wasn’t deleted before the manifest was created. I can include manifests when I put them on patchstorage.

It is a fat32 file system. I think if you replace the mv with a cp and rm it gets rid of that error, I’ve tried that locally and it seems to work:

create_install_package.sh

Also it looks like if I install the same module twice the install goes through but the unzipped directory isn’t deleted once it deploys.

Punchy I thought I’d alreadyextended it to 64 steps, have you changed the time divisions?

With punchyl I just increased the range of the punchy_beat parameter and changed the name (originally it was 1-9, I increased it to 64). So it does slower sequencers, not longer ones.

[thetechnobear]

Not uninstalling first was an issue I fixed in os 3.1, I’m guessing your still on 3.0

[aus10]

Yes, that was the case, thank you! It appears the organelle’s default midi out channel is 1, and that’s the channel the synth was expecting.

[bomboy]

So, I’m working to make a module from the Vocoder RL patch. The keys don’t seem to be affecting it in any way.

I removed the USB and reloaded the USB drive. Started Orac, and loaded up the Vocoder RL patch. When I went to look at the code again. I noticed many of the receive and send objects reverted back without the -$1. Is that normal? Any ideas on what I may be doing wrong?

note: i kept the reverb and all of the effects just to make sure i didn’t delete anything important my first time around.

[thetechnobear]

@bomboy

I noticed many of the receive and send objects reverted back without the -$1. Is that normal?

No

the module.pd is a separate file, perhaps you saved the wrong file, or forgot to save it before switching modules?

[bomboy]

Double checked. I still had the previous main.pd file. Maybe it was loading it?
I followed the directions side by side while watching your video. Added the -$1 signs where needed. But I’m not seeing a display. I’m also not getting any audio out. Could I upload what I have done in a zip and you look it over? Or should I send the dsp script? I’m going back through watching the video while working on it again to see what or if I missed anything.

Not sure if this helps or not. But this is the prompt the DSP script is giving me.
receive~ outR-m0: no matching send
receive~ outL-m0: no matching send
It says that two more times then
loading definition for m0: modules/F-Vocoder RL/module.json
pack_symbol: wrong type
loaded:Vocoder RL into m0: bang

[thetechnobear]

the videos are not edited, so what I do in them creates working modules, no secret changes made off cam

Post the zip file with the module.
But make sure it’s got the -$1 first, I’ve not got time to make it work, just time to see if something obvious is missing.

[bomboy]

I appreciate it!

Vocoder RL.zip (30.5 KB)

[thetechnobear]

ok,

• when mixing InL etc with output from subpatch you want to use +~ , not ~
  (~ will do amplitude modulation )

• the hanning window is not quite right, particularly the resize, I think I might have already done this in one of the other modules, perhaps check there? (sorry, id need to fire up the organelle to go check this properly) … that’s where you error comes from

• module ID, don’t use spaces. make it F-vocoder-RL, (actually id drop the RL fullstop)

• similarly, id not put special chars in the paramid’s might work, but asking for trouble

• KontrolModule, wrong name , its not U-vocoder RL, it should be F-vocoder-RL (see above) , this is why its not displaying anything

• [pd latch] needs some work

• n_tune, should probably be just a float, and in the patch you can just do [r n_tune-$1]-> [ / 100 ] ? (currently looks a bit odd) but id have to go check the original patch, to see what you intended here… is is suppose to be cents, +/- 1 oct

apart from that, yeah ditch the reverb, this is F-reverb anyway, so user can use if they want, or select another.

but its pretty close, I think the hanning is the bit might have you scratching your head

[bomboy]

This is such immense help for me. I tried me best to follow the steps. From the other patch. I’m still not sure what commands do what. Still learning as I go. I may have several more questions but really does help me. Seriously can’t thank you enough!

[bomboy]

Would not getting the hanning-window correct still prevent sound from passing through? I made all the other changes minus the latch. Could that be my issue?
Side note. Honestly, I’d just as soon take the whole thing out since I never felt it really served a purpose.

And for some reason, I’m still not getting a display on the screen. Other than the Latch.
I also removed the RL and made the necessary changes every where else. As well as removed the Reverb.

Currently this is what it looks like. (will attach photo in a moment)

[thetechnobear]

ok, had another quick check of you zip

you have removed all the commas from the lines in the module.json
you have also removed a square bracket and } on the last lines
(go look at one of the other modules)

you have

{
    "name" : "F-Vocoder RL",
    "display" : "Vocoder RL",
    "parameters" :  [ 
        ["pct","n_tune","Tune",-1200,1200,0]
        ["pct","n_squelch","Squelch",0,100,0]
        ["pct","n_wet/dry","Wet/Dry",0,100,0]
        ["pct","n_reverb","Reverb",0,100,0]
    ],
    "pages" : [ 
        ["pg_main","Main",["n_tune","n_squelch","n_wet/dry","n_reverb"]]

you need

{
    "name" : "F-Vocoder RL",
    "display" : "Vocoder RL",
    "parameters" :  [ 
        ["pct","n_tune","Tune",-1200,1200,0],
        ["pct","n_squelch","Squelch",0,100,0],
        ["pct","n_wet/dry","Wet/Dry",0,100,0],
        ["pct","n_reverb","Reverb",0,100,0]
    ],
    "pages" : [ 
        ["pg_main","Main",["n_tune","n_squelch","n_wet/dry","n_reverb"]]
    ]
}

having the hanning window will cause no sound as it basically is there to stop clicking by creating an envelope

you can see in the [pd fft-analysis] where it multiplies it by the inlets
you could just connect the inlets to the next part to avoid this temporarily, to see if you can get the rest working
but I would not remove it for release, as you will be able to hear it, and it looks like it might also affect the fft analysis. (i.e. the clicks would get included in the rfft)

[bomboy]

Question about parameters. Specifically the “tuning” on the Vocoder. If it’s not a percentile. And I need to add the +/- 100, what is the command I would use in the object box?

Would it just be + 100?

Also, you called it. That hanning-window has me scratching my head raw. Surely I’ll get it at some point though. I keep looking towards the nori sampler for a basic idea.

Sorry to be bombarding you with questions. I just can’t find any other resources about making modules.

[junklight]

I knocked up a quick module I wanted - a dead simple probability gate on a midi stream - one setting: percentage chance of note data passing by. Musically this is a good way of adding a quite an organic feel to things I find and I use this technique a lot in my music (and there is a good video of Brian Eno doing the same somewhere ).

I may add parameters - I wondered if having a note range where the probability applies perhaps…

I’m super busy with work but managed to knock this up quickly in gaps between meetings

Once I’ve got a few modules together I’ll put them all in a GitHub repo - presumably with either MIT (my preference) or GPL if necessary

Dropbox - Link not found

[bomboy]

Does anyone know what the $window-size-$1: not enough arguments supplied means?

[thetechnobear]

@bomboy

Question about parameters. Specifically the “tuning” on the Vocoder. If it’s not a percentile. And I need to add the +/- 100, what is the command I would use in the object box?

ok, so ‘percentile’ is no different from anything else… its the same as using float, except the units display are %

the thing about the n_tune parameter is you want to look at what it does afterwards, which is it sends into to mtof
…, so thats a midi note where 1 = semitone, so if you are passing in -1200, 1200, id assume you want to just divide by 100…, ie… so its -12, +12 semi tones (i.e. an octave)

@bomboy

Does anyone know what the $window-size-$1: not enough arguments supplied means?

unfortunately this is where you need a bit more pd knowledge
so you’ll see in the patch [; window-size 1024;] ,this is actually ‘message’ shorthand for [1024] ->[s window-size]
so thats not going to working, as really you need windows-size-$1 , but if you remember in my ‘conversion’ video, I explained how $1 wont work with messages, (due to syntax) so you need to use send

however, your error i think is coming your changes in hanning window, where you want trying to send the symbol into [pack f s] , so you put this into the first inlet which you have said is a float.

basically you actually want that pack, to feed in two parameter into the message, which should end up being
[;hanning-$2 resize $1;] but frankly this is easier to do with [send]

(I think also you have introduced a connection from that hanning resize message to samplerate~ which was not there before)

again, go check my conversion video where I made this change…

you’ll see its subtly different… (you can also check out the S-norisampler module on patchstorage to see what it looks like)

one thing to perhaps note… when you have it right you will actually see the graph in the hanning window look like an envelope

I know its all a bit tricky, there are a few pd things which are in play here (hence why I suspected it might trip you up) , its not really anything to do with modules, rather just getting a bit familiar with what is possible with PD messages and what is not… I think thats the bit of ‘missing knowledge’ here, the rest is looking pretty good.

[bomboy]

Okay.
Fixed sending the symbol into the samplerate.
Fixed the message to say [hanning-$2 resize$1;]
Put [symbol $1] -> [pack f s] -> [hanning-$2 resize$1;]
With [b] leading to the [symbol]
Fixed the tuning
Changed the message from [;window-size 1024< to [s window-size-$1]

Still no sound. And receiving the error $hanning-$2: not enough arguments supplied

Even though I’m close to pulling out my hair. I’m can definitely tell I’m learning quite a bit.
Anyways, provided more photos below for clarification.

[thetechnobear]

you need a space between resize and $1

[bomboy]

Alright, so I tried the space. For some reason I still can’t get sound out of it, and I’m getting this error message.

$hanning-$2: not enough arguments supplied

Thoughts?

[thetechnobear]

I think I need to see a new version of module to know where u r, hard to follow screenshots

[bomboy]

I understand. I’ll post a new zip tomorrow morning when I get to work.

[bomboy]

Here you are sir!Vocoder.zip (5.0 KB)

[thetechnobear]

ok, your issue is, when you switched to using send, you forgot to send in the window size, so you need

with this the hanning window looks correct, not tested the rest of the patch

[bomboy]

Just made the change. But still no audio.

I am seeing an error pop up that says
receive~ outR-m0: no matching send
recieve~ ourL-mo: no matching send
It repeats that two more times. Then when I load up F-reverb into the second module that same error comes up. Is that normal?

[thetechnobear]

Yes, this happens when it’s switching modules.

I’d need to load it up properly to find why no audio, the hanning window looked correct, so could be further up , not studied the patch too much, or changes made.

What I would do is trace the signal path, see where you lose the audio.
(Look at tabwrite~ to see how you can plot graphs of the signal)

[bomboy]

Okay, so I changed the audio in’s from [inlet~ inL] and [inlet~ inR] back to [r~ inL] and [r~ inR]. That seemed to do the trick. But I think I may have messed the tone up. when I use the keys to affect the voice it just sounds really off. But still. Progress!

[bomboy]

FIXED IT!!! It’s working and good to go!!! Thank you SO MUCH for your help. There is absolutely no way I could have done this without it.

Edit: Spoke to soon. Reloaded it. Sometimes it works sometimes it doesn’t. I’m thinking the issue may be in the “tune” section.

[bomboy]

The [pd latch] would only deal with the “latched” notes, correct?
It wouldn’t affect the tone in any way, would it?

[bomboy]

Anybody wanna take a look at this and see if they can find out why the keys aren’t working? I’ve been trying to straighten this thing out what feels like a lifetime at this point.

F-Vocoder.zip (5.0 KB)

[shreeswifty]

Pd lessons?
maybe a patch converter can be invented or a drag and drop do-hickey.

i really want to try to make some modules i just havent found the time to learn orac yet

[bomboy]

Pd lessons are definitely something I’ve been considering. Especially since I learn best under a hands on basis.

Honestly, I don’t think the modules are difficult. It’s just my own ineptitude on PD in general that has held me back and caused hiccups.

[Lazaruz4]

PD. It looks easy but it’s daunting.
I’ve avoided it myself because I hate getting stumped and then obsessed with a problem and I feel like that’s all I’d encounter when I try and get my hands dirty. Gonna try anyway!

[TheDeadFarmer]

@shreeswifty if by patch converter you mean something that could auto-convert patches to orac modules I think that would be incredible (though I don’t know if possible?). I’m currently scratching my head at why some of the orac S modules sound different to me than the original organelle patches. Anyone have insights I’m all ears.
edit: sorry if this is technically off topic!

[thetechnobear]

Patcher Converter is not really feasible, as it would in places be required to parse the patch to understand its logic - very difficult/impossible.
Even a basic attempt would take more time than I have available.

Sounding different - knob scaling on frequencies is different in places (linear vs squared). Or an issue in translation, again most likely to be around a knob/parameter
I’ll eventually take a look but I’m super busy at the moment, and there’s some higher priority items I’d like to get done for 1.1

[thetechnobear]

Sorry, when I get time I will take a look at this - but … (insert usually excuse)

—————

Pd , like any programming language takes time and practice to get used to, you have to go through fixing bugs etc, so you know what they look like.

All programmers create bugs/ hit issues, it’s just the more experience you have, the quicker you can recognize and fix them.

No shortcut there sorry

[junklight]

@thetechnobear - quick question:

In your module.json thing for setting up the parameters - is there any support for text based parameters? ie choose from a list of short text strings?

I’m guessing not - but just checking

also I presume that the module.json you use in the likes of rngs is similar to the one in orac (I’m making my grid thing standalone to start with so I don’t need to worry about multiple midi channels - one step at a time)

[thetechnobear]

No support for text yet (well there is but not exposed ;))
The reason is this needs to be enumerated types , to allow for remote control.

you will see I ‘get around’ this currently in some patches, by sending text to the aux line, which shows what the number means - but this is just a workaround.

@junklight

also I presume that the module.json you use in the likes of rngs is similar to the one in orac

Module.json is same format, and the interaction is very similar.

to use outside of Orac you (currently) have two choices:

• copy orac, and use its structure, and delete the extra module slots, and put in fixed routing.
• copy one of the Kontrol Series patches (including Kontrol externals etc)

this is because in Orac 1.0, Kontrol requires module slots, as it sends data to paramid-$1 (in 1.1 theres an option to turn this off)

id go for option 1, as its more compatible for when you want to move to a module

@junklight

(I’m making my grid thing standalone to start with so I don’t need to worry about multiple midi channels - one step at a time)

what do you mean by this?
are you saying, you need to send multiple midi channels?

what I personally would do is make the grid a module (or possibly just a router module) , and send to the active module… you can see how you can do that in one of the router modules , look for actmodule.pd ? basically this is where the organelles ‘r notes’ gets converted to s notes-$1.
its actually very simple, in fact, I suspect this will take you less time (once you figure it out) than writing a pd patch.

also, what nice in orac, is you (in the future ) move to full control orac from your ‘grid’ which special key combos (e.g. switch active module) … and of course, this will really help you if you want to run this on another platform e.g. rPI/Onda

[junklight]

ah cool

I’m kind of porting the patch from the standalone 1/2 written version I made - and now I need some infrastructure using the organelle stuff rather than writing it myself

I’d kind of started on moving it to a thing based on rings but it sounds like I’d be better doing a bit more figuring out and going the whole hog in to orac (which is where it was intended to go anyway).

More tomorrow though - I’ve spent the whole day in a baking hot field at a tap dance competition my daughter was in - a long, painful and excruciatingly boring day and now my brain is goo - good job I love her so much…

[maaark]

Hi all! Since Orac’s been released, I’ve been mainly using my Organelle for fun and in projects. It’s basically the best thing that happened to mobile music making for me. Thanks again @thetechnobear!

To thank Mark and also contribute, I’ve made my own chord making module as well as ported two popular Organelle patches: bpach’s RE-150 Tape Echo patch and callmesam’s Space Kittens…

https://github.com/markijzerman/mij.orac

You can find my patches here. Still haven’t gotten around to making a .zop. Is there a quick way to do this on my mac @thetechnobear?

I hope you guys can use this in your music making, let me know/send me videos!

All the best!

[Wannop]

Hey that chorder module is so good! Thanks for sharing.
The conversions are really great too.

[andy]

@maaark

I’ve made my own chord making module

It seems good, but I wondered if you could explain it a little bit. Is there a way to sequence it in order to alter the rhythm?

[andy]

or if i chose a different module set-up (like, 3x3+1) could it then be used in addition to the polybeats sequencer, for example?

[maaark]

Right now, there’s no way to sequence it in order to alter the rhythm. It’s clock is synched to the master-bpm, so yes, you can use it together with Polybeats. I want it to be able to use different rhythms though. Will look into it later, or fork it and do your own alterations!
It’s also lots of fun if you put an arpeggiator after it!

[andy]

i see. actually, i’m guessing it wouldn’t sync with polybeats. they would just run separately.

i’d love it if there was a way to change the rhythm, or just if it could accept input from a sequencer!

[maaark]

Aha, I thought you meant running at the same BPM…

Anyway, I’ll see when I get to it. Otherwise, you’re free to make any change you want!

[Wannop]

F-buffershufflr.zip (1.9 KB)
can anyone tell me how i screwed up this adaptation of an old shreeswifty upload?
Displaying fine… just ‘no sound’
think it may be an issue with the contents of the subpatches? they are the objects bufferfx1s and pd lfo1
it’s an effects module for mangling input sound n it’s rate good.

[maaark]

Not able to test atm, but what happened to me when I was porting over patches is that there was a lot of send/receive-combinations in abstractions that used a “$0-” in the name. As far as I understand this does not work with Orac (better check with @thetechnobear…).

I took them out and gave them normal names (using a text editor and some regexp actually, as it was in there quite deep).

I think this is actually NOT the right way as now they’re global variables, so one is only able to use one RE-501 module at a time. I hope Mark can shine some light on this!

[thetechnobear]

Nope $0 can be left as-is , $0 means they get a unique name per subpatch which actually is what we want.

Sorry, I’ve been busy with other things , once I get time I will take a look , as it’s possible I’ve missed a ‘gotcha’ that your hitting.

Unfortunately with pd is pretty bad at ‘namespaces’ , and sometimes fixing is rather dependent on what the patch is doing.
But honestly without looking at the patch, then working out what it’s doing - it’s impossible to say.

[Wannop]

Cheers, I’ll continue experimenting and hopefully i discover the solution and share. If anyone does get a chance to have a look in the meantime - i’d be very pleased.
I’ll have a go at a different conversion too i think, maybe the new c&g one!

I had an idea today - a sidechaining function for dipping one chain/module signal for anothers. Obviously though, beyond my ability!

[bomboy]

Can you imagine the sonic goodness for vocals by combining CA Filter and DUST?!?

[maaark]

well… I couldn’t get the Tape Echo to work when keeping the $0’s… Will look into it later.

… The problem is that the $1 (also for the parameter knobs) does not work in abstraction patches (so in a sample-voice.pd for example). So I have to use global send/receives…!

[thetechnobear]

$1 does work in abstractions, you have to send it in, i usually find it easier to add to the end, so it might not be $1, but $5…
(we need to be careful here, this is ‘standard pd’, so everything thats possible in pd is still possible)

i suggest you look at the 50 odd modules i already did, i think you’ll find i had to cover most situations

[maaark]

OK. I’ll have to go over the global send/receives I made later then.

For now, I added the tape synth (originally by @Fuurthur, made it polyphonic! sounds great!), lo-fi piano (by @seanearl which uses @Henrik’s samples) and warbly ukelele (by @seanearl).

The Chorder module now also accepts note input to advance to the next chord.

https://github.com/markijzerman/mij.orac

[Wannop]

Amazing contributions! Do know if it’d be possible to re-mono the tape synth module for another version? I love the voice stealing/glide sound on this track and immediately thought of tape synth when i heard it - but i couldn’t ever figure out how to make it the ‘right’ kind of mono to get the sound.

[andy]

@maaark

The Chorder module now also accepts note input to advance to the next chord.

I have a question, where does the note input come from? External midi?

[Wannop]

Or another module. I powered it with polybeats and it created a really cool pattern morphing effect to the chord changes!

[andy]

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?

[andy]

gah! now I see that there is an option on the screen to allow it to accept the notes! thanks! it’s amazing now!

[thetechnobear]

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,
because:

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’)

changes required:

• dont pass audio thru in the modules
  optional changes
• 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 ,
e.g. seq->synth->fx1->fx2
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)

panning

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 )

[Wannop]

sounds like a change for the best and not too troublesome while patchstorage is still yet to be flooded with modules

[junklight]

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! )

[ghostly606]

@thetechnobear

(note: Orac 1.1 will need users to ‘reinstall’ 3rd party modules… but they can use 1.0 modules without issues)

Was just away to ask this.

[wo3]

This seems like a good idea.

Please smooth the mixer so there is less zippering.

[$1 20{
[line~]
[*~]

[WyrdAl]

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!

[thetechnobear]

@wo3

Please smooth the mixer so there is less zippering.

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

@WyrdAl

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.

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)

panning UPDATE:
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.

[JEREMYWY]

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.

[thetechnobear]

not currently,

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…

[oweno]

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.

[thetechnobear]

definitely worth musing over

@oweno

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.

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 …

audio
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)

midi
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.

[Wannop]

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.

[oweno]

@Wannop

Is is a control/signal issue?

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

[Wannop]

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

[Wannop]

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?

[chrisk]

@Wannop have you had a look at how the Loop Jam Rec patch handles looping?

[Wannop]

I’ll have a look see!

[Wannop]

hi guys
can anyone take a look in here and tell me why the sampler-voice.pd isn’t hearing any knob, note messages or signals?
still got other things to do but scratching my head on this.
S-samplerstyleREC.zip (1.5 MB)

Getting a lot of ‘multiply defined’ and ‘stack overflow’ errors as I try to find ways to send values from the abstraction in module.pd to sampler-voice.pd

[Wannop]

@thetechnobear @chrisk @oweno
What dya think? If you have time.

[oweno]

are you getting stack overflow on this one (that you uploaded), or in trying other things? I haven’t loaded it, but I opened on my computer and I didn’t see anything right away. stack overflow is usually when an object output gets connected to its input (either directly or by way of send / receives) causing an infinite loop, so you might want to double check naming of send / receives.

[Wannop]

SamplerstyleREC Module:

I started again trying to convert this, thinking i would find it easy after a bit of practice. Nope!

I am getting ‘multiply defined’ errors for the object [throw~ samp_voice_out]

Dont understand this, as i thought the whole point of the throw~ object was to sum signals. Its not problematic in the original patch.

Also, the [loadbang-$1] object doesnt seem to do anything to initiate the samples into the read tables on module load.

Are there some special differences when it comes to abstraction when converting patches using Orac?

[thetechnobear]

I use loadbang-$1 all over the place, so definitely works ;). If your in an abstraction and have passed extra parameters you might have offset it?

Throw should sum, Orac won’t change that behavior- again I think it’s in a couple of modules , but honestly I prefer adding outlets so I can scale the audio on summing

Generally, no Orac doesn’t/cannot change Pd behavior at all - all the $1 stuff is about making sure parameters are unique to the module.
(And loadbang-$1 is due to Pd having a bug where loadbangs are not sent when modules are dynamically loaded - you can see this also in the IDE )

[Wannop]

Hmm, I’m stumped then! When I was converting constant gardener I tried using loadbang-global to get the tables working as they didn’t seem to respond to r loadbang-1$ and it worked in that conversion. Not in this one though. I’m kinda patching in dark though, still missing some basic knowledge hence the constant questions (sorry folks).

[Wannop]

@thetechnobear

I use loadbang-$1 all over the place, so definitely works ;). If your in an abstraction and have passed extra parameters you might have offset it.

Can you elaborate on this at all? Not sure I understand what you mean.

[thetechnobear]

post what you have, (and a description of what’s not working) , and I’ll see if I can spot anything obvious.
don’t really have time to run it, but sometimes a fresh set of eyes can spot things.

@Wannop

I’m kinda patching in dark though

yeah, unfortunately with coding (and i guess many things) that only gets you so far…
now that you have some practical experience, might be worth glancing thru some of the PD texts,
you’ll be able to gloss over most of it as you know it,
but you’ll probably find nuggets that’ll make you go “oh, thats why it thats why that patch does that”

@Wannop

still missing some basic knowledge hence the constant questions (sorry folks).

no worries, thats the best way to learn.

I’ll also say, I didn’t find many good ‘advanced tutorials’ on PD (not that i looked really hard ), most things i learnt by experimenting…

but be thankful, if you think the general PD documentation is scarce/bad,
the documentation on the externals/ C api - is virtually non-existent, I’ve resorted to looking at the pure data source code to work that out.

[Wannop]

Thank you for your time and advice!
S-samplerstyleREC.zip (1.5 MB)
I am using inlets and outlets for each of the samplerstyleREC voices now, which has bypassed the throw~ object issues. I am using loadbang-global to initiate the sample tables, which i would like to do with r loadbang-$1… but for some reason cant. The decay and sample speed messages are not making it into sampler-voice.pd for some reason. It does however record and play up to 24 samples in mono or poly… so theres that.

F-trigfilter.zip (4.4 KB) If anyone is really loving these non-working patches im uploading here is another one. It’s supposed to be the note-responsive bandpass filter from ‘CA Filter’ without the cellular automata. Not sure why im getting no wet signal from this one. Enjoy!

[thetechnobear]

ok,
the loading-global in your module.pd can just be replaced with loadbang-$1
you can see this is being called, as at the top of the patch you can see
[ print loaded:samplerstyleREC into $1] is executed.

the sampler-voice.pd is as i said,
you need to pass in parameters to abstractions, this is how $ arguments work in PD
(nothing magic for orac here )

so the simplest way is in module.pd change each voice to:
[sampler-voice 1.wav 0 $1]

then in sampler-voice.pd you can use
[r loadbang-$3]
as this you now have sent the module parameter as arg 3

( alternatively you could pass in as arg 1, then shift all the args in the subpatch by 1, but that’s more work, and brings no benefit )

you can actually see me doing this in many modules, as its quite a common thing to have to do.

in fact it was so common, i covered it in my ‘Orac: Converting patches to module’ video, around half way thru (circa 17:00 mins)

(same video also i think describes how i moved away from using throw to outlets)

---

btw: do NOT use loadbang-global, this is not a substitute for loadbang-$1

it has nothing really to do with loading a particular module, and will means your module will start doing things any time ANY module is changed in orac, which will harm performance and useabilty.

his is only use where changing a module can affect other modules - primarily this is used by the router module, since the tempo is stored on it, so changing it / loading a preset will mean that other modules need to react if they stored the tempo.
in this case the impact is very minor, it’s just updating an internal variable.

[thetechnobear]

oh. btw… watch the rest of the video… your patch also suffers from some of the other issues which i explain how to tackle e.g. table name, and the messages used to read/write to it.

(basically your module will have issues if you load more than one instance of it into orac )

i know, i know the video is at a really fast pace, it covers a huge amount of ground - but i had to keep it reasonably concise to have any chance that anyone would watch it and not be frightened off ‘giving it a go’ - the latter half in particular is probably worth watching a few times, and making sure you understand exactly why i do certain things.

don’t be fooled by some of my ‘flippant’ comments, like “all you need to do is …” for a deeper understanding, you may have to do a bit of experimentation/reading up to understand what Ive done.

e.g. $1 in the subpatch example , is only because its got 1 arg, its different if you have multiple args like you do

but again, its a starting point, go check the other modules, one of the reason i did so many was so that i knew the underlying orac architecture could cover all modules needs

[oatsincoats]

Had this one kicking around for a bit:

F-tremolosync.zip (8.2 KB)

This is a clock sync’d stereo tremolo, with Beat divisions and a Mix Control.
Feel free to comment/critique!

[Wannop]

Nice one mate! Thanks for sharing, look forward to trying it.

[oweno]

Can a module send a signal to cause an Orac preset to load? or is this not a good idea? I guess the module could cause itself to unload if the preset that it called didn’t include itself… the idea is a module to quickly select presets (and even sequence them?)

[thetechnobear]

yes, the KontrolRack object has a ‘loadpreset’ message

it also has nextpreset, prevpreset, savepreset, savecurrentpreset,
and quite a few other messages, like selecting modules, loading modules

is it a good idea?
theoretically it should be technically fine - I use a similar mechanism for switching presets with midi program change control messages.

there could well be a disruption of audio (aka audio glitch) , unless you know there are not sounds being generated (because you’d abruptly might take a wave output of 1.0/-1.0 instantly to 0.0), of if not a glitch, then audio going silent for a very brief time. (milliseconds id guess)

how quickly it will be done is interesting… if a large number of modules remain the same, then it should be pretty quick… iirc, i will just end up reloading the parameter data , rather than having to reload modules. (remember when I change modules, Im re-writing the pure data patch!)

it seems very fast when done from the UI, but if you started automating, thats when you would really noticed the time taken

knowing about what presets there are…
ok, so unfortunately, im not publishing the ‘resource list’ to PD (it is published over OSC)
but you can use getsetting dataDir to find the location of the data directory,
(if you look at any of the sample based modules, you’ll see i use this same trick for the media directory)

---

conceptually the only issue I see, is your likely to adding some ‘rules’ e.g. what are the presets called,
or generating a large number of presets, which might make the normal preset menu feel uncomfortable.

perhaps just bare in mind, that the way its setup in Orac 2.0, is that a user can just rename a preset by renaming the directory to what ever they like
(at some point Id love to implement a ‘keyboard’ on the organelle so they can rename presets from within orac)

also Im not sure how you will be able to make preset selection much quicker…given you have will first have to select the module (of your preset selector) before you can select … seems going to the menu is quicker

---

one parting thought… perhaps a way for you to test proof of concept/viability of sequencing preset changes is simply to use an external sequencer (or daw) to sequence preset changes via program change messages via midi - if it works satisfactorily there, then it might be ok from within PD.

[oweno]

This is great, thanks for the info. I was just thinking about a proof of concept… I’m thinking of presets as sections of songs (also thinking of sequencers that would begin playing upon recall, etc), so you can piece together music by selecting the sections, maybe the change happens at the top of the beat. hitting a button to make a selection like this would have a natural feel. true, you would need to get into the preset selection module to make a selection, but once there it is only 1 press, versus a ‘find and select’ using the encoder.

but yeah, it does open a can of worms about which presets are the ones mapped to the keys, and how are they named, etc… mostly just curious if it could work, which will probably depend on if modules have to be reloaded, especially modules that load samples which might interrupt the flow.

@thetechnobear

if a large number of modules remain the same, then it should be pretty quick… iirc, i will just end up reloading the parameter data , rather than having to reload modules. (remember when I change modules, Im re-writing the pure data patch!)

so if no modules change, the patch is not changed, and Pd doesn’t have to load anything, right? but if even one module changes, the patch changes and Pd will then have to load all the modules?

@thetechnobear

perhaps a way for you to test proof of concept/viability of sequencing preset changes is simply to use an external sequencer (or daw) to sequence preset changes

thanks for the tip… I’ll just make a patch for a 2nd Organelle

[thetechnobear]

@oweno

so if no modules change, the patch is not changed,

from memory, I believe not, it should just load the new set of parameters from the preset for that module.

@oweno

but if even one module changes, the patch changes and Pd will then have to load all the modules?

nope, it’ll only load that one module … it only rewrites the slot that has changed.

@oweno

thanks for the tip… I’ll just make a patch for a 2nd Organelle

sounds like a plan

its one of those things, that perhaps if we try it, then we will find some small oddities - some of which might be easy fixes…
e.g. i think even if changing/loading new modules turns out to be problematic (*), we should be able to make it that changing settings works instantly - which would be an interesting thing to sequence in itself.

(*) the only thing that I do know is currently the audio will be briefly interrupted, as I have to stop the dsp, to prevent Pure Data audio glitching as it loads the module file.
(this we saw in Orac 1.0, so I fixed in Orac 2.0)

i’ll be interested to hear how the proof of concept works out

[oweno]

@thetechnobear

i think even if changing/loading new modules turns out to be problematic (*), we should be able to make it that changing settings works instantly

yeah even if the modules had to stay the same and just the settings of those modules could be selected and sequenced it would be fun… I’ve been playing a lot with setting up a few chains and then trying to make different sequences or scenes keeping the same module setup, sort of like musicians playing specific instruments. quick change presets might work well under this setup.

Another random question: for graphics messages, I ran across this trying to figure out how to do a graphical representation of page parameters:

Orac 2.0

yeah graphics modules I want to be careful with, I need to do a couple more to show developers how I want them to work. (the current ones just show the mechanics, not how to interact with parameters) its REALLY important that developers use the graphics to render what the parameters are doing, and that they change the underlying parameters to follow any changes they are making . (this is like the VST model for those that know such things) - and also make the underlying parameters available to…

but I don’t fully understand. Is there a way to merely disable the default param text display and show a graphic instead?, for example and ADSR page that displays the envelope as 4 lines, instead of text prarams.

[thetechnobear]

@oweno

Is there a way to merely disable the default param text display and show a graphic instead?, for example and ADSR page that displays the envelope as 4 lines, instead of text prarams.

yes… this is pretty easy to achieve…

the answer is made up of a few concepts:

• you can define a parameter, but if you don’t put it on a page then it will exist but not be displayed
• you can define an empty page(s), i.e. one without any parameters on it… so it be displayed blank, and so give you a ‘canvas’ to draw on

ok, so the next thing to understand , is you need to only draw when ‘that page’ is displayed, which is why there is a message to tell you when pages are changed.
(see polybeats module as an example of this)

now… the next thing is, as mentioned above, is you will want to use parameters - because this enables the values to be saved/loaded in presets, midi learn etc.
as above, that’s ok, as they can be hidden.

you will still get the values via the sends as normal… so the last piece of the puzzle is there is a message called ‘setparam’ which sets the parameter

its defined as:

setparam module_id param_id value e.g. setparam a1 m_transpose -12.0

note:
a) getparam
there is also a getparam,
getparam module_id param_id defaultvalue sendsymbol
but this is usually not needed since you can usually just use the normal receive mechanism
b) do not be tempted to ‘send’ the value usually sent by kontrolrack
this will just get things out of sync

---

the only disadvantage with custom displays like this, is they will not work with ‘remote displays’ , since the rendering is specific to the organelle…
this might not seem that important for the organelle, as its got a display but I’ve got some interesting plans
e.g. controlling the orac on the organelle from a VST on your computer, for things like parameter modulation
this is likely not to work, since all though the VST will know about the parameters they won’t be on a page, and also the custom page will not be able to be rendered, since the render code only exists in PD.

anyway… thats not to say its not a good thing, e.g. i like the scope object.
its just why, at the moment ive tended not to put functionality in a graphics display that is not useable without it. (or like its not so relevant to a remote display)

[oweno]

thanks for explanation, this makes sense, still confused about this:

@thetechnobear

you will still get the values via the sends as normal

what is the module receiving if there are no parameters specified for a page? e.g. you don’t list any page params in module.json for the second page. so the second page can be used for graphics, but then you won’t receive any values at all, or no?

[thetechnobear]

preset being loaded, or if midi learn so you had a midi cc mapped etc

The main point is , the pages are ‘merely’ for grouping for display- parameters still exist and can be manipulated that don’t appear on a page.

Note: when I implement the mod matrix this will also allow for non displayed parameters to be modulated.

[oweno]

ok, that makes sense… so taking the ADSR example, we would:

• define params for attack, decay, sustain, release
• define blank page for graphics, called ADSR
• in the module listen for ADSR becoming active. lets say knob 1 is attack. When the ADSR page becomes active we receive oknob1 and use that value to draw the attack line on screen and also send the attack value back to kontrolrack ? (this is still where I’m unclear)
• implement getparam logic for keeping things updated from presets / modulation / cc

I’ll make a simple module as an example of this once I’m sure this is the right idea.

[thetechnobear]

@oweno

• in the module listen for ADSR becoming active. lets say knob 1 is attack. When the ADSR page becomes active we receive oknob1 and use that value to draw the attack line on screen and also send the attack value back to kontrolrack ? (this is still where I’m unclear)

This is where you call setparam

• implement getparam logic for keeping things updated from presets / modulation / cc

You probably won’t need getparam

Say you define the param as m-attack

You should just be able to use
[r m-attack] as you would normally ( when the param is displayed)

The only thing I’d need to test is if setparam will broadcast m-attack back to the Pd patch, I think it does/should.

[oweno]

@thetechnobear

The only thing I’d need to test is if setparam will broadcast m-attack back to the Pd patch, I think it does/should.

this appears to work. for example I just tried sending ‘setparam b1 as_cutoff 1’ (for the analog style module). the value gets sent back out, and I also checked it is stored when you save a preset. I did notice setparam takes a value 0-1 (pre scaling), is this how it should be? e.g. as_cutoff is mapped to 100-2100, so when you set as_cutoff to 1 using setparam, you get 2100 back…

[thetechnobear]

hmm, i thought it was in the scale of the parameter e.g. 100-2100
(and should definitely be consistent with getparam)

the only drawback (and perhaps why i did it like this originally) was if you use the scaled parameters, you need to know the limits (min/max)…
but i’ll take a look next time im in the code

[oweno]

ok cool ! thanks for the insights

also wondering if it would be easier if a module could just send a flag to suppress the display of a page… so the ADSR page could be setup as a usual textual display, but then if the module wanted to display a graphic page instead, it could just send something like ‘disabledisplay module_id page_id’. this would keep platform specific receives (r oknob1) out of the module. although all the oled display stuff is platform specific stuff already going in the module, so maybe this a moot point…

one other thing while discussing param scaling. a bunch of parameters when mapped to a knob work better as ‘log pots’. for example with something like delay time going from 0 - 4000 ms, at the low end of the scale you don’t get much adjustment. in Pd I often simply square the 0-1 knob value, so first half of the knob would go from 0-1000 ms… I was thinking about an attribute you could set in the module.json parameters list indicating linear or audio taper (or just a number to which the 0-1 input value is raised pre scaling)?

[chapelierfou]

Super stupid question :
how do you save the json file when edited ? (In the Organelle, editing with VIM)

[chapelierfou]

I tried to make a gain module as a first module.
Couldn’t make it work, would anyone check it please ?

gainmoduletattempt.zip (1.9 KB)

[TheDeadFarmer]

I’m looking to add a “gate length” type of parameter to some synth modules. Have seen various methods employed when looking at some patches and modules. Makenote (arpeggio synth, and ORAC polybeats), and vline~ (C&G pow pow polybeats) for example. My pd skills are VERY rudimentary - what would be the simplest way to try and add this parameter to an existing synth module?
*Notes will be coming into orac from external sequencer

(I apologize for having made similar posts in other threads. In hindsight I should have started here)

[oweno]

in module.json, the names of page parameters should match names of parameters, so

["pg_main","Main",["gain"]]

should be

["pg_main","Main",["gain_gain"]]

[oweno]

@TheDeadFarmer

I’m looking to add a “gate length” type of parameter to some synth modules

most synth modules will respond to note-on and note-off messages (essentially the same as a gate). so the length of the note or gate is determined by what is driving the synth (key presses or an arpeggiator or sequencer of some kind), usually this is the expected behavior of a synth (i.e. the notes getting played and their duration are best kept outside of the synth module). or are you thinking of release time? so when the note releases, specify how long it fades out?

if you really did want to set a gate length in a synth, you could use something like this:

[r notesIn-$1]
|
[stripnote]
|
[makenote]

so note offs are ignored (filtered out by stripnote), and makenote will generate a note off after specified duration.

you could also make a simple module that you could place before any synth that would provide this behavior, so you could use any existing synth.

[TheDeadFarmer]

I think release time won’t achieve the results I’m looking for as my MPC 1000 doesn’t have a master gate length per track parameter that can be adjusted in real time
I like having the notes cut off super short and being able adjust up from there (without having to change the original midi sequence’s note lengths). Thanks a lot for your suggestions, I’ll definitely give this a try!

Unrelated, this was such an embarrassingly simple mod that I almost hesitate to post it - allows one to use delay module as fx or aux send from a mixer - but maybe someone w 0 pd skills will happily find it some day: delayfxsend.zip (2.4 KB)

[chapelierfou]

Thanks. I still don’t get everything, but I should probably go through the video tutorial another time.

[chapelierfou]

Well, the module is not working. I’ve got nothing displayed on screen where I’d expect to have “gain” displayed.

[thetechnobear]

if no parameters are displayed , it’s most likely a syntax error in the json file.
If it’s just one parameter missing , then it’s a mismatch between param id in its def, and the page def

Tip: if you restart mother , then the stderr is redirected to the console for pd, and so you will see errors when loading modules in orac.

(fw_dir/scripts/restart-mother.sh or something lkke that )

[chapelierfou]

So, this is the json I’m using :

{
“display” : “gain”,
“parameters” : [
[“float”,“gain_gain”, “Gain”,0.5,4,1]
],
“pages” : [
[“pg_main”,“Main”,[“gain_gain”]]
]
}

Then in the module.pd, to use the parameter should I use [r gain_gain-$1] or [r Gain-$1] ?

[thetechnobear]

looks ok to me…, yes r gain_gain-$1 - you never use the display name. this is covered in my video.

also what Id recommend is look at any of the orac modules as an example, some of them are pretty simple in fact what I usually do (and i think i do in the creating modules video) is usually copy one as a starting point, then edit from there… easier to not make mistakes.

anyway, here is version of your module that works… I didnt do anything other than fix the module.json
(sorry, Im really busy until next week… and will be offline from thursday)

unzip into /media/orac/usermodules - then it will appear as test/gain
(e.g. on sdcard /sdcard/media/orac/usermodules/)

gain.zip (828 Bytes)

btw: this gain module isn’t actually needed, as the router already allows you to add gain - no?

if you want to allow for more gain, then what i would do is probably copy the router module, and then just edit module.json to change the max value on the gain … e.g. change to 400% if that’s what you want.

[chapelierfou]

Thanks a lot !

@thetechnobear

btw: this gain module isn’t actually needed, as the router already allows you to add gain - no?

Yeah I missed it at first. But still, I figured that it would be the simplest and best first module to do.

[chapelierfou]

Well. I don’t get it. Your files work, but whenever I make any change on my Mac and then re-upload it to the Organelle, it doesn’t work.
I’d like to edit it directly on the Organelle, but I don’t even know how to save the edited file…
Sorry I’ll move to something else, I don’t want to waste your time.

[thetechnobear]

Probably something to do with the editor your using, probably changing line endings or something.

Look for a ‘programmers / code editor’ , there’s quite a few free ones - some will explicitly have Json syntax support.

I use sublime text , for this on the Mac all the time, but don’t think that one is free.

( I do a lot of editing on organelle with vi but then old school )

[oweno]

@thetechnobear

but i’ll take a look next time im in the code

btw is the code for KontrolRack / KontrolModule public somewhere?

[thetechnobear]

@oweno of course … all my stuff is open source

its part of my MEC project

TheTechnobear/MEC

[oweno]

oh right… I was looking in the wrong place

[oweno]

Is there a way for a module to know it is about to be unloaded? so, for example, a sequencer module could flush notes before it disappeared.

[thetechnobear]

I’m adding [r unloadbang-$1] to next release

also (if i remember this time), modules ‘down the chain’ will automatically receive an ‘all-notes-off’ message (ctrl 127) when a module is unloaded.

e.g.
B1->B2->B3->B4
B2 module is changed, B3, B4 will receive ‘all notes off’ (ctrl 127)

note: Ive already coded all synths to respond to ctrl 127, and if a midi controller sends CC 127

[oweno]

@thetechnobear

I’m adding [r unloadbang-$1] to next release

Thanks!

Another question… I’d like to control all the chain output gains in the parallel router from one page, so I don’t have to dive into the router module each time. I could modify the router to make a page, but is there a strategy for making a ‘shortcut’ module that targets params of other modules? I started making a module that adjusts the router chain gains using setparam… this works, but I have to hardcode the module slot (works as long as router is in s1), and the parameters get stored twice: by the router and by my module which in turn sets the router. I guess if it works it works, but didn’t know if there is a better way

EDIT: To answer my own question, not the best idea to have a parameter of one module directly setting parameter of another module, sorta opens can of worms and overly complicated… in this case I just didn’t want to change the default router, but doing a custom router with a page for mix or pan or whatever is so much easier. I made a master mix page with all the gains (I made it the first page, so I also had to offset the keyboard page chooser so the first key is actually choosing the second page)… works great.

[TheDeadFarmer]

Is it possible to make a midi out “octave-switchable” module?
Perhaps just channel, velocity, and octave?

[thetechnobear]

apologies for being MIA

@oweno

not the best idea to have a parameter of one module directly setting parameter of another module, sorta opens can of worms and overly complicated…

yeah, this is the ‘struggle’ with modular,
modules have to be independent - otherwise you start loosing abilities to mix n’ match.
the ‘exception’ is the router, which my definition has to know what modules exists (and the slots) but even it does not know what ‘type’ of module is loaded into a slot.

of course, you could ‘break the rules’ as long as you’re clear to user what the rules are,
but its not something I can do in the general orac architecture as it would lead to limitations for module developers etc.

glad you found a way to ‘make it work’

@TheDeadFarmer

Is it possible to make a midi out “octave-switchable” module?
Perhaps just channel, velocity, and octave?

so like the current midi out module, but with the ability to fix the velocity and transpose notes?
sure, you could do this quite easily…
perhaps a better idea would be to create a separate midi fx though, that changed the data?

so you’d have
seq → notefx → midiout

the advantage of this is you could use it in different scenarios eg.
seq → notefx → basicpoly

I could imagine the module doing all sorts of things like:
scaling velocity, transposing, random/chance

its also a very simple module to write… as basically all you are doing is mangling the notes as it goes thru.

(advanced note: in orac 2.0 it can even mangle the channel as this is now part of the note and ctrl messages… this is how MPE works in Orac )

[oweno]

Is there a reason the module name (or shortend version of it) be prefixed to the parameter names in module.json? most modules have params like ‘bp_attack’ for basic poly attack, but ‘attack’ alone would work, right?

[thetechnobear]

yeah, no reason at all - they just need to be unique within the module.

[oweno]

I just put up a module demonstrating a graphical page with parameters… It is an ADSR that you can adjust on the graphics page (page 1) or on the standard text page (page 2).

https://patchstorage.com/adsr-graphics-demo/

@thetechnobear does this implementation look correct? one thing to note is the knob controls that set the params on the graphics page are bypassing the lock/takeover provided by kontrol, so they jump when touched…but I guess this mechanism could be added.

[thetechnobear]

@oweno

@thetechnobear does this implementation look correct?

yup that’s exactly what I was trying to describe

it highlights a couple of interesting points to note:

• I think what I need to do in module.json is some how ‘tag’ the graphics page as organelle specific, and that the ‘ADSR’ page is an alternative ‘text’ view. (i.e. the organelle does not need to display the ads page)
• parameters do not have to appear on a page, there can be ‘hidden’ parameters
  (ones that the patch uses/sets, but the user does not have access to because they are not on a page)

one thing to note is the knob controls that set the params on the graphics page are bypassing the lock/takeover provided by kontrol, so they jump when touched…but I guess this mechanism could be added.

yeah… thats an interesting point … this should probably be ‘configurable’ , in some way…

currently its built on same mechanism as things like OSC and MIDI coming in, and in these circumstances you do not want the take-over functionality.
(e.g. imagine remote automation from midi, it should immediately set value regardless of pot position)
so, the take-over is only required because we are using pots, so its very much hardware specific.

but I think it’d be wise to have some ability to handle this in Kontrol, as its a bit of a pain to implement in PD

[oweno]

@thetechnobear

parameters do not have to appear on a page

Right, mainly I put the second page to test that it was working (i.e. move value on one page, the other page is updating too).

---

I like the flexibility of this system. It also allows for things like using the knobs to control more than 1 param, or other custom knob to param mappings… the jumping values doesn’t really bother me, or a takeover mechanism could be added to the patch, been done before…

@thetechnobear

I think what I need to do in module.json is some how ‘tag’ the graphics page as organelle specific, and that the ‘ADSR’ page is an alternative ‘text’ view. (i.e. the organelle does not need to display the ads page)

Still wondering: for the simple case like this (1 knob to 1 param), couldn’t there be a way to just define one text page and then add a rack message ‘disable-display slotID page’? So when the module senses the page it just shuts off the usual text display so it can display the graphics. Then the module wouldn’t have to bother with setting params, implementing takeover, etc… of course you would only want this on Organelle, so the module could also sense if it was running on Organelle and only disable if so.

[thetechnobear]

@oweno

of course you would only want this on Organelle, so the module could also sense if it was running on Organelle and only disable if so.

this is really the crux of what I need to figure out…
how does orac have some code that’s running on some platforms but not others.
ideally this mechanism, would allows for different platforms to have different implementations.

e.g. perhaps a page is marked as an “organelle” page, and this causes a particular bit of PD to be loaded? but then there is a fallback page (to display the text parameters)

however, the other displays/controllers I do within MEC, and currently without graphics - so its not quite clear yet - for sure, one possibility is for other displays controllers to follow a similar model (specific osc graphic commands) , and its just MEC that does the rendering etc. (so basically its acting like mother host for other devices)

btw: so how does this all relate to the Organelle? why bother?
so, Im hoping I should get an electra.one quite soon… which I’ll be adding Orac support for.

Electra One

the idea here… is if someone wants to ‘extend’ the UI of the Organelle to something with more encoders and can display more parameters, they can then plug this into their organelle… and viola

so, I love that the Organelle is portable/self contained, so can take it out, and play on the sofa.but I also love that when Im using in my little studio, you can connect it up - so, I hook up it up to my mixer, sequencer, midi keyboard and other controllers… so now not ‘limited’ by that portable form factor.

[oweno]

@thetechnobear

e.g. perhaps a page is marked as an “organelle” page, and this causes a particular bit of PD to be loaded? but then there is a fallback page (to display the text parameters)

I guess my thinking was leave it up to the module to sense the platform and act accordingly, then you don’t need to add any special organelle page, only the default text page which the module would override (disable-display) if it knew it was running on an Organelle…

The Electra One looks really cool! How is the parameter display configured, is there some kind of edit process?

[thetechnobear]

@oweno

I guess my thinking was leave it up to the module to sense the platform and act accordingly, then you don’t need to add any special organelle page, only the default text page which the module would override (disable-display) if it knew it was running on an Organelle…

hmm, but my thinking is… you’d likely want to have some ‘text’ parameter pages as well.
i.e. I suspect organelle patches would be a mix of text and graphics.
and when that’s the case, you need to know the ordering of the pages.

for sure it needs to be different from the current ‘blank page’ = you are on you are own…
and you’re likely right that its going to need a certain amount of pd code controlling whats going on.

The Electra One looks really cool! How is the parameter display configured, is there some kind of edit process?

generally there is an editor to set it up, and sent to the electra one via usb, the electra one then stores it, so that it can be completely standalone (e.g. with hardware synths)

however, they are working on an api, so that over USB you can reconfigure the display etc.
so the general idea is Mec running on the Organelle will send it the parameters to display, and then route users changes back to orac.
they are keep that the display should be more component based, rather than raw drawing…but are open to more possibility of more components types (e.g. perhaps they could have things like vumeters/adsr/scope?)
I think this is quite a nice approach, since you get a more uniform display, and its easier for things to interact with . (e.g. every app doesn’t have to work out how to draw a dial )

[oweno]

@thetechnobear

I suspect organelle patches would be a mix of text and graphics.

right… I see how it could get problematic. Anyway, I like the the current approach, it works and is flexible, so maybe just adding an optional platform tag to the pages in module.json is the thing to do (so they can be skipped if not on that platforms). or maybe we’d also need platform exclude tag (i.e. text page excluded on organelle)

---

I’m glad to hear they are working on api for the Electra One, and sounds like they have careful thinking about using the components, etc… keeps the design and experience unified. how do presets work with something like this? does it need to receive all the params back?

[TheDeadFarmer]

Hi! I’m attempting to do the same thing with the bpm_seq arper that I did with the original - adding an octave transposition parameter. I think I’ve modified the patch in an equivalent way, but it’s not working I think due to something I’ve got wrong in the json. Here’s an image:

Guessing the grayed out “int” is indicative of a problem, though I’m not sure what/why…

[oweno]

Missing a comma at the end of the line before the grayed out “int”

[TheDeadFarmer]

Ha thank you! I saw it just before coming back here, (such an obvious error ) very much appreciate the kind and quick reply - helped me finish up these mods with confidence

[oweno]

@electrafa

the recent sequencer_bpm serie was made with a different type of clock (360 ticks instead of 24), can i ask why…?

Continuing this discussion…

Generally it would be good to settle on a unified approach for clocking in Orac modules. At the very least the clock module should output the beat as a phasor so modules can easily play in time. Dividing the beat into 24 ticks as MIDI clock does is woefully inadequate for expressing anything but the simplest divisions of the beat, so something with a little more resolution is desirable.

I like how Ableton LINK ouputs a beat 0-1 floating point beat phasor, so when I started working on the seqencer_bpm stuff the idea was to use this 0-1 beat phasor to drive everything… But it turned out to be much easier to deal with an integer beat phasor when building patches, so I settled on 360 ticks per beat (numbered 0-359). 360 is nice because it is easily divided, it has a nice ‘circular vibe’, and it is sufficiently high resolution (if it were more ticks it wouldn’t really matter since the scheduler in Pd doesn’t run that fast anyway).

So a module can expect a stream of numbers 0-359 every beat, with 0 at occurring at the top of the beat. This is sent out as ‘beat-clock’. Ticks are not repeated, so if the clock is running slowly, so we don’t see 0, 0, 0, 1, 1, 1, 2, 2, … etc, we always get 0, 1, 2. Ticks are not skipped, so if the clock is running quickly (i.e. ticks are going past faster than the Pd scheduler) we still always see 0, 1, 2. The clock module in the sequence_bpm collection has a [clockfix] object before the ticks are sent out which ensures this behavior, filling in any missing ticks so the modules always see 0-359 exactly. When the clock source is external MIDI (24 ticks per beat), we multiply by 15 to get 360 and [clockfix] fills in the missing numbers, effectively quantizing the beat-clock to 24 segments, but there is nothing we can really do about that…

That is the long answer for why 360 ticks… better resolution, easier patching.

[JEREMYWY]

Working on a step sequencer module that stores the notes in 16 slots in an array. I’d like this sequence to be saved. How can I get the save message to trigger a save function for the array? where is the return of that command? I looked for it but I can’t really find anything.

[oweno]

There are a bunch of modules that save stuff like this. Take a look at the seq2 module that comes with Orac for example, specifically this area:

This prepares read and write messages whenever a preset is saved or loaded.

[Lcchy]

Hello everyone
I would like to start developing Orac modules and I am looking for a good set up to do so.

I want to forward the PureData windows of the running Orac instance to my computer so that I can edit them, interact via the hardware and listen to the results at the same time.
(i.e, I don’t want to have to reupload the patches after each change)

Do you know how to do that ? What kind of set up do you have ?

I am using a Rpi built into the fates dac so it might not be exactly the same as on the Organelle although I am interested in how you do it on the Organelle as this might be a hint.

For now I have tried to launch Orac from Sidekick using the hardware, after having restarted Sidekick via ssh -Y, but the windows don’t get forwarded. (This method works for other Sidekick patches)

I have also tried to launch Orac directly by running the ExecStart command from the orac.service from which I took the nogui flag out first:
/usr/bin/pd -rt -alsamidi -nogui -audiobuf 4 mother.pd main.pd
This has launched and forwarded the patches successfully, I can edit them and midi in is working, but as expected, the hardware interactions (fates encoder) don’t seem to work and the fates screen is not showing the Orac pages.

(I also wanted to thank thetechnobear for this amazing and very inspiring construction of his!)

[Lcchy]

Ooh I just found this.
You have to cast through VNC.
Sorry for the disturbance

[Lcchy]

Just in case someone stumbles upon the same difficulty:

I still couldn’t make it work through VNC. Yet, it works (flawlessly) by forwarding the pd windows through ssh -Y in a standard way. I had to add the line :

Environment=DISPLAY=localhost:10.0
(as orac is run in a service, the DISPLAY variable needs to be set again as it does not access the user environment, as far as I understand)

into /etc/systemd/system/orac.service as well as the flag -gui to the pd call in the same file and then sudo systemctl deamon-reload in order to commit the changes.

Please correct me if I’m wrong or if there is a better way to do this

[thetechnobear]

well…
first this is not relevant to the Organelle, as the Orac on the Organelle does not get run as a systemd service, it gets run directly from mother host.

so its probably better to discuss monome orac on the lines thread to avoid confusion.

Orac, Sidekick, Pure Data and SC for Norns

as for how I do development on orac on rPI/monome (which is the same )

• have sidekick initially run Orac ‘normally’
• log into rPI/norns via ssh
• stop the orac service
• run vnc (as per wiki https://github.com/TheTechnobear/NuiLite/wiki/Using-VNC)
• set display, and then run Orac manually from command line. i.e. full pd command line.

the key difference between Norns/rPI to Organelle, is the the former interacts with the display via MEC service (*), whereas the Organelle does this via PD thru mother host.

the ‘advantage’ of the above approach, is it means I don’t need to keep changing the orac.service file back n’ forth - it be very inefficient to run it permanently in ‘gui’ mode, so you only want do do that whilst actively developing
also, when Im doing development I always have an ssh shell open to rPI anyway … to handle things like git and stop/starting processes - so really having orac as a service is not that helpful/productive.

(*) you may also find some times, you want to restart the MEC service during dev, if it gets confused about Orac restarting/modules changing - it shoudn’t be necessary all the time, but sometimes its helpful to help it ‘reconnect’

[Lcchy]

Thank you so much, this was very instructive! (I had also never understood how MEC was useful for Orac)
This is quite cleaner indeed I tried to launch the patches directly like this before but never got the hardware interaction to work (I was missing MEC…)
This also works through ssh -Y.

Sorry that I have polluted this thread with some rPi/norns specific stuff, maybe someone can delete them.

(I wanted to add your instructions to the Nuilite wiki but couldn’t edit it)

[Audivit]

Do anybody know if there’s a command to reload the saved preset parameters into a module?