sequencersampler's Recent Posts
i am running the aalto au in max 6, osx lion.
what message do i need to send [vst~ aaltocomponent] to start up and sync the aaltos host sequencer?
also... does it not accept midi in?
The ability to run the plugins with both MIDI and OSC (using Soundplane, etc) is essential. PLEASE!
I haven't looked into MIDI MPE for this application. I suppose now is the time! :)
Thanks for the info.
I know about the zones. How could we exploit the multi-touch and polyphonic capabilities of the voice module in OSC with MIDI zones though? If Aalto is set to 2 voices and the zone has a CC slider mapped to timbre then that CC controls timbre for both voices which isn't the same as using OSC where two touches along the y axis can independently modulate the timbre parameter for each voice.
In this instance, it'd be useful to then source the pitch/gate from a MIDI arrangement. The sequencer could certainly still control the gates and pitch but the small step size of the sequencer is limited compared to the ability to work with MIDI arrangements in the DAW.
A small apology for this somewhat redundant post as I've written about it in the past.
Primary Case: MIDI sequence feeding pitch and velocity data to the KEY module. While this sequence is running the Z, DY, X and Y parameters of the Soundplane can gesturally control the plugin without having to worry about influencing the pitch and gating. This has been critically missing functionality imo. While the sequencer can sort of approximate this paradigm it's not as flexible as working with as MIDI arrangement while focusing on gesture.
Secondary Case: Either gate/velocity OR pitch information from the MIDI running while working with gestures. We might want to have the gates coming from a MIDI sequence while using the Soundplane for pitch information. Or...Maybe we want the pitch coming from a MIDI sequence while using the Soundplane for gate/velocity information.
Decoupling these control paradigms will open up performance avenues. I think the core idea is cherry picking where we want pitch and gating information to come from.
Other users please chime in if you'd like to see this or have other approaches in mind.
Thanks for your time and input rsdio. There's a lot to think about here. I'm going to digest this and respond later.
Amazing updates. Appreciated.
The inclusion of the MIDI expander is very welcomed.
Velocity on Gate/Trigger is lovely.
Is the current idea that the main module will support up to 8 touches? Or are we looking at building up an array of touch pair modules as shown above and interfacing them to the main module?
This is great news. Thank you for sharing.
Kaivo stops responding to MIDI note messages when OSC is active. I want to retain control of gates derived from MIDI notes while using the Soundplane to control Kaivo (with OSC active). Is this configuration possible? Did I overlook something?
In my previous post I forgot to mention that once you know what notes are choking up the patch, avoid those to prevent the issue.
Yeah, choke or "lock up" is the behavior I am referring to. In order to remedy the issue I have to start another instance of Kaivo.
From a conversation with Randy:
"Physical models are prone to this sort of “blowing up” if not all stability conditions are met. I always attempt to use theory to insure that this can’t happen, but sometimes reality produces a different result."
Not sure if it's the root of the same problem your patch is experiencing, but I've had Kaivo "blow up" with certain notes in certain patches (usually higher notes). Kaivo gets stuck and I need another instance.
Thoughts on a Scala interpreter for the module and pitch CV?
Since pitch CV has been mentioned, I'm assuming you are referring to 12TET 1v/Oct.
How feasible would it be for this module to be able to download zone maps that interpret Scala files similar to Aalto & Kaivo's KEY module? This is really important. One of the most satisfying parts of using the Soundplane with Aalto and Kaivo is the ability to utilize Scala files with a continuous surface.
This thread does not include an attachment for the Soundplane 1.2 client.
Also, the 1.2 client does not have the custom mappings (zoneExample1, etc).
I'm looking at the SoundplaneZonesOSC max patch and have a question about receiving note & controller data over OSC. Will the OSC maintain full data resolution when reading data those .json MIDI zones? I'm hoping to maintain as much resolution as possible and will avoid zones if it comes at some kind of resolution cost.
Another question: Are there Soundplane App examples of OSC zones?
I'm familiar with the MIDI zone examples but didn't notice any OSC zone examples.
Or were you referring to manipulating the Soundplane Apps OSC data in Max/MSP (or similar) to target the desired behavior?
Ah!!!! I did overlook something. OSC direct to Kaivo.
Soundplane touches can conjur the OSC data to target and send to Kaivo, while the Kaivo KEY module listens to MIDI.
It felt like I was making this extra complicated.
Any patchable parameter! An OSC note/gate bypass would be needed in the Soundplane client.
Is Aalto located in the same location as the rest of your plugins?
In the Live 9 Preferences menu go to the Filer Folder tab. Under the Plug-In Sources section do you see where it says "Use VST Plug-In System Folders" and "Use VST Plug-In Customer Folder"? Try enabling the Customer Folder (set this option to on) and then target that folder with the "Browse" button. After this click "Rescan" at the top of the Plug-In Sources tab. Does Aalto appear now?
You could use a Utility plugin in your DAW/host environment to force the plugins output to mono.
I'd like access to the OSC inputs while still being able to use MIDI quantization relative to a DAW transport. For example, using a MIDI arpeggiator > Kaivo while still having OSC control. This isn't possible if OSC disables Kaivo's ability to respond to MIDI notes.
Randy, would it be possible to lift this restriction?
where did the max patches go?
@randy (and all),
beyond the designated categories in the kaivo sample bank, what sort of guidelines did you adhere to when selecting, recording and/or designing samples for the granulator? while nearly anything can sound great, there tends to be particular samples that i return to. i can analyze what it is i like about particular samples, but i'm hoping to gain insight as to what sort of methods can yield better success when designing sounds to put into kaivo's granulator. i think this sort of practice is both simple and very complex :)
-given that the samples can be 1-4 channels....dynamic amplitude plays a huge role when it comes time to modulate the sample x/y position. a mix of silence and loudness produces a lot of dynamics when modulating the granulator, whereas a consistent amplitude level across 1 channel will be more static.
-transients seem to have a heavy influence on the response.
-when using MIDI to Pitch, Kaivo seems to quantize the grains to the specified pitch, which implies granulator sources can be highly atonal and still be used harmonically.
yay! nice work randy. looking forward to experimenting.
"note quantize with adjustable filtered snap time"
what does adjustable filter snap time allow for?
thanks for all of your hard work madrona! it's appreciated. looking forward to watching the development over the next few weeks.
my experience lead to similar findings, except i found the VST to always crash Max 6, whereas the AU is stable. (i am referring to loading the .component and .vst files, not the vst~ object in Max 6)
host sync is not working. internal seq is.
thanks for the report and help. let me know what you learn.
for any curious about the experiments -- i have sent the aalto .component all kinds of messages and transport information in max 6, but have been unable to successfully run aalto sequencer set to host sync.
has anyone experienced success running aalto's host sync (engaged) in versions of max prior to 6?
i will keep experimenting and report back. aalto and max 6 will be quite the duo.
the combination of people, soundplane, and coffee is perfect.