]]>
I've also uploaded this workspace.
The second side to this drum sequencer will be that it has a customizable number of step sequencers which can be wired to parameters on a VST as well as saved in the pattern store. I'm thinking it may make sense to move the velocity stepper into that sub-patch as well, and have a combo box per voice that allows you to select whatever particular params you are wiring for that drum stepper.
If anyone with experience in scripting could take a look at this workspace (which, by the way, I think will start causing issues if it is re-tuned for polyphony), I'd really appreciate it. There are a handful of scripts* in there that I think others would appreciate, but I hesitate to share them while I am still experiencing breakdowns and other oddities with this patch.
* In this workspace: 'Midi Switch', 'Pass on Change (Array)', and 'Pattern Store'. Also developed for this project are 'MidiPlex' and 'MidiMux'. These come in handy with the polyphony mode. I'll make another workspace that includes them.
Statistics: Posted by ceasless — 27 Aug 2013, 22:11
]]>
Right now I am actually observing some frustrating behavior with regards to the array passing script I've posted above. In restarting this project I've run into a situation where step data is not passing back to itself through the script and thus you are unable to change any of the step values.
Hopefully these screenshots will help to explain.
This first one shows in the trace output of the patch cable that the array passing script works as expected, so long as it is not connected back into the step sequencer input.
The second one shows that, after being connected, the value of the step I am trying to change is not reflecting back into the step sequencer. The new value I am inputting just disappears.
I've uploaded this workspace which contains the sub patch featured in the screenshots above.
I've also been experiencing a lot of crashing when working on this stuff, but it generally happens when exiting the program (and after successfully saving). I've been basically running under the assumption that it has something to do with the scripts that I've been writing, but as far as I can tell from reading the documentation and looking at other scripts, they are written as they should be.
By the way, it works fine in the same sub-patch when working with sequenced switches instead of steps. Give the workspace a try and you should see what I mean.
Statistics: Posted by ceasless — 25 Aug 2013, 22:09
]]>
But it seems like Olivier is very good about streamlining conversion between types, whenever that is not ambiguous.... and whether an array has changed is not ambiguous......
Statistics: Posted by woodslanding — 25 Aug 2013, 06:50
]]>
My use case however requires that it have a 'base signal' that is then overridden by an array that has changed.
I am definitely planning to share all the pieces I've put together so far, but I'm still working on the puzzle (crashes and other instabilities that most likely stem from some of the scripts I've written and/or the patching logic). Also, I've learned a lot since I began on this drum sequencer patch (especially with regards to polyphony), so a re-build is currently under way. I'll post it in this thread when I get a chance.
@woodslanding - Interesting mention of invisible conversion as a Usine philosophy. That actually runs a bit contrary to my patching/scripting experience so far but that is technical rather than philosophical. But from what I've seen I don't know how I'd have an input that takes both single values, arrays, midi, and text (for instance). I'd like to hear more!
Here is the 'Pass on Change (Array)' script:
CODE:
//////////////////////////// Pass On Change (Array)/////////////////////////// parameters declarationvar changer : tParameter;var constant : tParameter;var outx : tParameter;// initialisation : create parametersprocedure init;begin changer := createParam('changer',ptArray); setIsOutput(changer,false); constant := createParam('constant',ptArray); setIsOutput(constant,false); outx := createParam('out',ptArray); setIsInput(outx,false);end;var i,len : integer; var v : single;// Callback procedureProcedure Callback(N:integer); begin case N of changer: begin len := getLength(changer); for i:=0 to len-1 do begin v := getDataArrayValue(changer,i); setDataArrayValue(outx,i,v); end; setLength(outx,len); end; constant: begin len := getLength(constant); if len > 0 then begin for i:=0 to len-1 do begin v := getDataArrayValue(constant,i); setDataArrayValue(outx,i,v); end; setLength(outx,len); end; end; end;end;// Global variables//////////////////////////////// main proc//////////////////////////////Procedure Process;begin end;Statistics: Posted by ceasless — 24 Aug 2013, 14:32
]]>
]]>
Btw, i'm sure some users will be happy with your pass on change script for array, i remember some of them looking for this some times ago..
Statistics: Posted by nay-seven — 23 Aug 2013, 20:36
]]>
The more I'm using Usine, the more I'm realizing that thinking in terms of patches is a different beast than raw programming. Already I've realized that the magic of polyphony makes at least one of the scripts I've written redundant. So I can tell that there are problems that I've solved just by writing a new script that could be more easily solved using patches than I realized.
One script I've written that I can't seem to find an equivalent for though is 'Pass on change (Array)'. This takes two arrays, one which is the 'constant' (in my cases so far, the array output of sequenced switches/steps). The other is the 'changer', in my case this is the output of a 'Pattern Store' script. The output of this script then goes to the input of the the sequenced switches and it allows me to load patterns in while at the same time maintaining the ability to directly change the sequence.
I notice that there is a 'Pass only if changed' module already available in Usine, but it differs from mine in that it only takes one input. And that input is not of array type, so I figure it's not really useful in my case.
Is there a more efficient way to have a sequenced switches/step module take as input some patterns that are stored elsewhere, while at the same time allowing it to control itself in the usual manner?
(Also let me know if a patch would be better for understanding what I mean than my description above).
Statistics: Posted by ceasless — 23 Aug 2013, 12:14
]]>