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.