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
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.
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?
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 )
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).
Can you elaborate on this at all? Not sure I understand what you mean.
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.
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” 
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.
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!
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.
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 
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!
Nice one mate! Thanks for sharing, look forward to trying it.
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?)
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.
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.
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?
thanks for the tip… I’ll just make a patch for a 2nd Organelle
from memory, I believe not, it should just load the new set of parameters from the preset for that module.
nope, it’ll only load that one module … it only rewrites the slot that has changed.
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
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:
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.
yes… this is pretty easy to achieve…
the answer is made up of a few concepts:
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)
thanks for explanation, this makes sense, still confused about this:
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?