Coming back to pd after a stint in the real world. Have an idea for a patch.
Would it be possible to crossfade between 2 rj lib save states?
My idea is to adopt a 2 turntables kind of philosophy, where you can change the state in the save state or 'deck' that's not being read. Thus you could cue up the next preset then crossfade over to it or do a quick cut over to it.
The interpolation of parameters I can manage.
I'm just wondering how I would have to modify the saving mechanism in the rj abstraction so that I could have two running side by side?
Cheers all, John.
Hi,
On Mon, May 13, 2013 at 01:44:39AM -0700, JF wrote:
Coming back to pd after a stint in the real world. Have an idea for a patch.
Would it be possible to crossfade between 2 rj lib save states?
The rj saving (or sssad saving, which is at rj's core) can manage parameters of various character - symbols, for example, ot lists with symbols or numbers, that maybe are intended to be used as integers. So crossfading everything blindly is impossible.
I'm just wondering how I would have to modify the saving mechanism in the rj abstraction so that I could have two running side by side?
I would suggest you make some kind of wrapper. You can remote-control all rj parameters via sends and receives, so it's probably not necessary to change the rj state management itself.
Frank Barknecht _ ______footils.org__
I'm just wondering how I would have to modify the saving mechanism in the
rj abstraction so that I could have two running side by side? <<
it's been a long time since i looked at rj, but from memory it uses something similar to sssad for statesaving, doesn't it? So, you assign keys to each of your abstractions and save according to those keys, yeah?
in that case, i would just bundle my entire 'scene' into a bigger parent abstraction, and use a $0 (or similar) prefix to all my state saving keys so that state loading would be local only to that parent, and not to the other channel's parent.
On Mon, May 13, 2013 at 11:27 PM, Frank Barknecht fbar@footils.org wrote:
On Mon, May 13, 2013 at 11:51:26PM +0900, i go bananas wrote:
You're right: The state savign in the rj library is just "sssad", which is included as a copy named [u_sssad]. There are some additional goodies, but basically that's it.
Frank Barknecht _ ______footils.org__
Thanks Frank.
Yes I figured that I would have to let rj/sssad handle the static storage and implement
the crossfading myself.
What should I wrap?
Sorry I'm still a bit rusty after so long away from Pd.
I was playing with it last night and had some thoughts.
Let rj/sssad store and load static presets as normal and implement a parameter crossfade
at read time.
Create 2 read-only, parameter holding banks to load presets into. A sort of turntable A and
turntable B. So presets can be loaded into either bank A or bank B (usually the one that
isn't playing at the time).
Have an rj style gui that represents the patch's current parameter values. When a
global crossfader is moved, make the current value of a parameter fade/interpolate
towards the value in the required preset banks.
e.g.
Cutoff current value is 70
Move the crossfader left towards bank A where the preset value of the cutoff is 10
Cutoff current value changes smoothly from 70 to 10
Does it sound like I'm on the right track?
Also I'll point out that I'm patching for a computer not an iWhatever. I just find the rj
abstractions to be very helpful. (Cheers!)
Thanks in advance, John.
Thanks!
I presume this approach would mean having two copies of the 'meat' of the patch running side by side?
Correct me if I'm wrong.
I'm hoping to only have one copy of the guts running and have the crossfading done to the parameters. As my machine is getting older now.
I'm not looking to crossfade audio at the end. This will be a midi note and CC generating patch for my synths and samplers to record and to play live with.
Cheers, John.
ah yeah, sorry... i had assumed you meant different things on both sides of the crossfade.
so yeah, you could just use one patch for the guts.
here, i'm attaching a little patch to show a possibility for xfade with sssad (you'll have to incorporate this into sssad yourself, but hopefully won't be too tricky)
On Tue, May 14, 2013 at 4:21 PM, JF saintidle@yahoo.com wrote:
So this is a kind of compositional technique, "continuous parameter space transition", or a slippy synth or whatever you want to call it and there's a couple of tricks you can use to turn any set of synths toward this;
lists like {1.0 0.4 0.01 0.333 0.0}
states P throughout a composition and we want the sound to slowly morph through them all, reaching a new state every T seconds
are only read at event boundaries, like envelope ADSR values.
Solution:
Break up the list into new list pairs where every other value is the morph time T. With a morph time of 3.0 seconds we get {1.0 3.0} {0.4 3.0} {0.01 3.0} {0.333 3.0} {0.0 3.0}
Send these to [line] or [line~] objects
If you have events like notes also running and retriggering envelopes then arrange the parameter data with them all at the head of the list {E E E E P P P P P}
Use list split to pull those off, store them in a list and resend them on each note event. Send the remainder to the bank of [line] objects, once only.
This is such a compo
http://obiwannabe.co.uk/sounds/sparkle.mp3
There are no "events" in this, just one long single note. The first bit that sounds like chords shows off the potential for more standard composition. Actually the sounds are 'timbres' of the note, where the harmonics are carefully set up to give a chord like structure. I picked a bunch that sound nice together and then found a set of quick (20ms) transitions along a path between them. The second movement just picks five or six random coordinates in the space and moves between them slowly to show the kind of crazy electroacoustic sort of sounds such a synthesiser can make.
On Tue, May 14, 2013 at 12:21:10AM -0700, JF wrote:
However don't rule out audio for speeding up the crossfade itself. Attached is a very fast way of interpolating two 64-element parameter lists using audio operations in a subpacth, that is suspended after each interpolation run using a [switch~] object. Drive this at your desired metro-speed and you have a nice and tidy interpolation system. By using a different block size in the subpatch and bigger tables, you can also extend this to bigger preset list sizes. And it still is very fast - much faster than if you would use a message based approach which involves list unpacking and so on.
Frank Barknecht _ ______footils.org__