[chuck-users] Seqs, Design and Usability (Slightly OT)

Kassen signal.automatique at gmail.com
Sat Mar 10 07:52:34 EST 2007


Veli-Pekka Tätilä wrote:

Hey that's something new I just have not thought about, thanks for an
> enlightening idea. Maybe that's why usability folks are not too happy
> about
> the trend of trying to look like the real thing in media players.


I think so, yes. With instruments I think it's worse then with media
players. Media players tend to be switched on and left to run, maybe some
tracks will be skipped, occasionally the user might rewind a interesting bit
and late at night the bass might be filtered out on the eq. Instruments will
be used in a more intensive way over a longer period. Fortunately a little
more thought goes into DAW controlls or drawig out expressive modulations
would be a total nightmare instead of a chore but I still think this a prime
example of how ChucK can be used to make our own tools where the standard
ones are lacking (see, not so OT at all!)


For an example where real knobs shine, consider a knob that has a notch in
> the center so you can easily zero a signed parameter. IF it is well done
> the
> notch is prominent enough to make it easy to stop the knob yet is not on
> the
> way when you try to rotate the knob fast over a large range. Do any soft
> synths have such a feature?


Some softsynths try to get close to something similar by automatically
scaling the mouse sensitivity... That would lead to issues with the tablet I
experimented with and I doubt your maginfier likes it. For general usage it
might help.




>
> Interestingly, here is what the Windows interface guidelines say about
> mouse
> operation:


Yeah... Once again the theory is there but practice is a sad affair. The
good news is that if you'd like to experiment with the mouse you can read
it's raw data in ChucK using the mouse Hid. That will completely ignore
where on the screen it is and allow you to link movement directly to sound
which could be interestig. Ignoring screen location might be a good thing if
you have trouble with vision anyway.


Interesting, I do know the ancient PC game quest for fame is. I'm able to
> play it using the 640x480 reso using the rhythm view that is. But that's
> seriously OT. Welll check out:
> http://en.wikipedia.org/wiki/Quest_for_Fame


Ah, that looks like Guitar Hero except without the focus on the usage of the
screen. I'd love to find that controller, looks like serious fun.


[ChucK v.s. modulars]

> So more like programming, well that's familiar territory for me outside of
> ChucK its just I've yet to adopt that mindset in ChucK. Well, could you
> give
> a concrete example?


Generally with ChucK you depend more on modulations being based on time
periods and much less on extracting info from zero crossings in controll
signals. Another thing is that due to their structure multiple processes
running in paralel on modulars need to be re-synced often (likely every
cycle to avoid drift and edges arriving a fraction too early or late) with
ChucK that's not nesicary and timing is much more dependable. Even in
digital modulars (the Nords, Tassman, likely Reaktor and MAX as well)
vertical flanks will always be quantised to the sample rate which can and
will result in issues with timing and execution order.

That's the main thing, for me. On the downside: in ChucK going back and
forth between audio and controll signals tends to be cpu intensive. I'd
still like a way to generate events based on zero crossings without needing
to use a if-then loop based on ZeroX.last() at a rate of 1::samp because
those loops are so expensive.


[multiplexing]

> Say I'd like to create a basic multiplexer for selecting OSc waves, one
> out
> of three. Here's the first way that comes to mind:


<snip>

Yes, that's a good example.

On thing you could do is create a array and asign different osc's to the
locations in it. Even if you don't use that for adressing you could use the
ChucK and unChucK operators to connect and disconnect the oscilators. The
advantage of that is that ugens that don't end up at the DAC (inderectly) or
blackhole won't be computed which will save cpu.

That's of cource quite different from a normal multiplexer in architectue
but for 3 osc's it will save you about 2/3 of the cpu time which is quite
good and not something that a Nord Modular could do. Admittedly the NM has
real wave-form switching so in this particular case it's moot.


Have a Ugen reference named osc and chuck it to DAC. Then switch on the
> value of another variable using nested if else if else if constructs to
> assign instances of the different oscs on that ugen ref, to select that
> particular wave for output. Is that a good strategy?


Yes, i think so, particularly if you combine it with unchucking the
connection. A array to hold the locations and a function that would take the
one osc to be conected as a parameter could deal with it for you. The two of
those could be made into a class if you'd  like to use the same thing a few
times.



What if I need to use a similar multiplexing structure in ten places in an
> instrument and also the amount of inputs and outputs varies?


Arrays, I'd think... That would depend on the exact needs.


Which brings me to my
> unanswered questions about where to put class files, how to import them in
> projects and so on?


You can have any number of classes stright in your file. If you'd like to
import classes you'll need to make them public and put them in a seperate
.ck file (one public class per file) and machine.add those before using
them. This is dealt with in the manual and examples. It's not a 100% without
issues yet but that would be the way to go about it.



>
> So apparently there's the value inf. But What's the literal value I use
> for
> comparing if something is infinite?


I have no idea, never ran into that. Ge or Spencer will know.

 [sequencer design]

>
> Although they lack the Fruity style auto fill and rotation functions,
> which
> I mentioend when you asked what kind of features would be cool in the
> ChucK
> seq. But they are simple yet sufficiently powerful devices


Well, and cheap and cheerfull. They have some very good interface ideas but
the channel-bleeding on the outputs of mine is atrocious and the MIDI
implementation in braindead.



> One exception, obviously if you use a function for adding new notes, you
> Should be able to turn on silent steps, too.


Yes, that's a area with big questions. I'm trying to make note input (with
regard to timing) uniform with beats but notes have so many other properties
as well that that sceme leads to exceptions in the interface. Ironing those
out in a sensible way is a good way of losing some sleep <grin>.


> I'll read the manual more carefully, thanks. I hope it can mix multiple
> sources or if that's not possible, have multiple instances control
> playback
> acurately.


You can have both and indeed; the manual and the examples will help there. I
warmly recomend editing/recombining and remixing the example files for
aspirering ChucKists.



>
> So adding FX in the sample level, you know that could work.


Yes, infact some of the basic otf example use sample-retrigering from drum
rolls. This is quite easy to do.

The major hurdle
> here would be the ability to use a common file open dialog or some other
> browser to add samples. OR a dir which is polled for wave files
> periodically
> and updates the samples used. Fruity's ability to auto preview samples in
> a
> pattern is a real timesaver and the same is true of the Forge open dialog.


Ok, yes, that would be hurdle but you can asign a key to reloading the
sample you are using if you'd like to have a wave-editor next to ChucK.
Auto-scanning a directory isn't going to work just yet.


[sid]

>
> It is but it is limited in terms of timing and range of parameters. YOu
> cannot use controllers to freely sweep the noise frequency with ease,
> which
> is trivial in C, especially on the C64 itself.


Then I suppose the only option will be adding a bit of C like that and
recompiling....


I don't find it very natural myself, but at least it retains the gaps in
> intuitive places. It would be worse if esc was the first step. YOu could
> maybe also blink the numlock, scrolll lock and caps status leads for
> accents, portamento or whatever to indicate something about the current
> step. Idea stolen from MAME.


I'd like that too. I think a HID-out that could do that is on the list as
well.


Here's another mapping for accessing large patterns quicker:
> f1-f4 pick one of the four stteps in the current beat supposing 1/16 notes
> f5-f8 select the beat in a measure supposing 4/4
> f9-f12,esc pick the measure in a 4-measure pattern to edit
> This is much like binary numbres in that the right-most digits, if we
> number
> bits in a little endian:ish way, control larger quantities.


Yes, makes sense but needs some thought. Because I like to play live one of
my prime demands is that it needs to be usable in the dark, after drinks and
under stress.

Yours,
Kas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20070310/becc56d5/attachment-0001.htm 


More information about the chuck-users mailing list