<br><div><span class="gmail_quote"><b class="gmail_sendername">Veli-Pekka Tätilä</b> wrote:</span><div>&nbsp;</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hey that&#39;s something new I just have not thought about, thanks for an<br>enlightening idea. Maybe that&#39;s why usability folks are not too happy about<br>the trend of trying to look like the real thing in media players. 
</blockquote><div><br>I think so, yes. With instruments I think it&#39;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!)
<br>&nbsp;</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">For an example where real knobs shine, consider a knob that has a notch in<br>
the center so you can easily zero a signed parameter. IF it is well done the<br>notch is prominent enough to make it easy to stop the knob yet is not on the<br>way when you try to rotate the knob fast over a large range. Do any soft
<br>synths have such a feature?</blockquote><div><br>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.
<br><br><br>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>Interestingly, here is what the Windows interface guidelines say about mouse
<br>operation:</blockquote><div><br>Yeah... Once again the theory is there but practice is a sad affair. The good news is that if you&#39;d like to experiment with the mouse you can read it&#39;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.
<br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Interesting, I do know the ancient PC game quest for fame is. I&#39;m able to
<br>play it using the 640x480 reso using the rhythm view that is. But that&#39;s<br>seriously OT. Welll check out:<br><a href="http://en.wikipedia.org/wiki/Quest_for_Fame">http://en.wikipedia.org/wiki/Quest_for_Fame</a></blockquote>
<div><br>Ah, that looks like Guitar Hero except without the focus on the usage of the screen. I&#39;d love to find that controller, looks like serious fun.<br><br>&nbsp;</div>[ChucK v.s. modulars]<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
So more like programming, well that&#39;s familiar territory for me outside of<br>ChucK its just I&#39;ve yet to adopt that mindset in ChucK. Well, could you give<br>a concrete example?</blockquote><div><br>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&#39;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.
<br><br>That&#39;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&#39;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.<br><br>&nbsp;</div>[multiplexing]<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Say I&#39;d like to create a basic multiplexer for selecting OSc waves, one out<br>of three. Here&#39;s the first way that comes to mind:</blockquote><div><br>&lt;snip&gt;<br><br>Yes, that&#39;s a good example.<br><br>On thing you could do is create a array and asign different osc&#39;s to the locations in it. Even if you don&#39;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&#39;t end up at the DAC (inderectly) or blackhole won&#39;t be computed which will save cpu.
<br><br>That&#39;s of cource quite different from a normal multiplexer in architectue but for 3 osc&#39;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&#39;s moot.
<br>&nbsp;</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Have a Ugen reference named osc and chuck it to DAC. Then switch on the<br>value of another variable using nested if else if else if constructs to
<br>assign instances of the different oscs on that ugen ref, to select that<br>particular wave for output. Is that a good strategy?</blockquote><div><br>Yes, i think so, particularly if you combine it with unchucking the&nbsp; 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&#39;d&nbsp; like to use the same thing a few times.
<br><br>&nbsp;</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">What if I need to use a similar multiplexing structure in ten places in an
<br>instrument and also the amount of inputs and outputs varies?</blockquote><div><br>Arrays, I&#39;d think... That would depend on the exact needs.<br>&nbsp;</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Which brings me to my<br>unanswered questions about where to put class files, how to import them in<br>projects and so on?</blockquote><div><br>You can have any number of classes stright in your file. If you&#39;d like to import classes you&#39;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&#39;s not a 100% without issues yet but that would be the way to go about it.<br><br>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>So apparently there&#39;s the value inf. But What&#39;s the literal value I use for<br>comparing if something is infinite?</blockquote><div><br>I have no idea, never ran into that. Ge or Spencer will know.<br><br>&nbsp;[sequencer design]
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>Although they lack the Fruity style auto fill and rotation functions, which<br>I mentioend when you asked what kind of features would be cool in the ChucK
<br>seq. But they are simple yet sufficiently powerful devices</blockquote><div><br>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.
<br><br>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">One exception, obviously if you use a function for adding new notes, you<br>Should be able to turn on silent steps, too.
</blockquote><div><br>Yes, that&#39;s a area with big questions. I&#39;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 &lt;grin&gt;.
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>I&#39;ll read the manual more carefully, thanks. I hope it can mix multiple
<br>sources or if that&#39;s not possible, have multiple instances control playback<br>acurately.</blockquote><div><br>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.
<br><br>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>So adding FX in the sample level, you know that could work.</blockquote><div>
<br>Yes, infact some of the basic otf example use sample-retrigering from drum rolls. This is quite easy to do.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
 The major hurdle<br>here would be the ability to use a common file open dialog or some other<br>browser to add samples. OR a dir which is polled for wave files periodically<br>and updates the samples used. Fruity&#39;s ability to auto preview samples in a
<br>pattern is a real timesaver and the same is true of the Forge open dialog.</blockquote><div><br>Ok, yes, that would be hurdle but you can asign a key to reloading the sample you are using if you&#39;d like to have a wave-editor next to ChucK. Auto-scanning a directory isn&#39;t going to work just yet.
<br><br>&nbsp;</div>[sid]<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>It is but it is limited in terms of timing and range of parameters. YOu
<br>cannot use controllers to freely sweep the noise frequency with ease, which<br>is trivial in C, especially on the C64 itself.</blockquote><div><br>Then I suppose the only option will be adding a bit of C like that and recompiling....
<br>&nbsp;</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I don&#39;t find it very natural myself, but at least it retains the gaps in<br>
intuitive places. It would be worse if esc was the first step. YOu could<br>maybe also blink the numlock, scrolll lock and caps status leads for<br>accents, portamento or whatever to indicate something about the current<br>
step. Idea stolen from MAME.</blockquote><div><br>I&#39;d like that too. I think a HID-out that could do that is on the list as well.<br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Here&#39;s another mapping for accessing large patterns quicker:<br>f1-f4 pick one of the four stteps in the current beat supposing 1/16 notes<br>f5-f8 select the beat in a measure supposing 4/4<br>f9-f12,esc pick the measure in a 4-measure pattern to edit
<br>This is much like binary numbres in that the right-most digits, if we number<br>bits in a little endian:ish way, control larger quantities.</blockquote><div><br>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.
<br>&nbsp;</div>Yours,<br>Kas.</div>