<br><div><span class="gmail_quote"><b class="gmail_sendername">Veli-Pekka Tätilä</b>&nbsp; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br>As you mentioned off-list some of the accessibility stuff is really OT here.<br>SO I&#39;ll skip and snip more than usual.</blockquote><div><br>It all kinda interacts. I imagine there must be more people who want to put ChucK in clubs.
<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;"> Again the heuristics here are that the<br>right-click menu is a power-user feature, you should not depend on people
<br>using it and so the functionality should be mirrored somewhere.</blockquote><div><br>I think you can seriously wonder how suitable sub-menus are for instruments at all. Verious synths -including ChucK if we look at programing and using the HID/MIDI/whatever a seperate- use two different interfaces for configuring and playing.
<br><br>It gets more tricky with pro-level keyboards and grooveboxes and so on. I don&#39;t think sub-menus are such a good idea there. Generally I think many instruments would be better with less but more carefully planned out features. The piano lasted centuries already; I don&#39;t think the mc303 will.
<br><br><br>Acessibility and playability have a huge overlap. You might find this PDF worthwhile, it&#39;s by ChucK co-author Perry Cook and on basically this topic;<br><a href="http://soundlab.cs.princeton.edu/publications/prc_chi2001.pdf">
http://soundlab.cs.princeton.edu/publications/prc_chi2001.pdf</a><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;">You mean a tablet PC, Yeah I can believe that.
</blockquote><div><br>Actually I meant one of those graphic designer tools to replace a mouse with a pen and use absolute (not relative) controlls. I had hoped the absolute desk-screen mapping would make me faster thanks to muscle memory but instead auto-scaling resulutions made it very unpleasant affair in Ableton.
<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;"> ANd how do you drag and drop<br>with a pen interface anyway?</blockquote>
<div><br>Exactly like with a mouse or with a chopstick on a dinner-plate.<br>&nbsp;&lt;grin&gt;<br><br>That&#39;s not the hard bit, asuming you are used to a mouse anyway.<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;">
 I&#39;m sure the screen reader mouse emulation does<br>not like it, either. IT can drag and drop in software, but only if the<br>source and destination show up as different focucible objects to the reader.<br>Needless to say dragging an arbitrary amount away from the center of a knob
<br>canot be emulated with current reader software.</blockquote><div><br>That would probably mean the same effect would be seen when drawing envelopes.<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>Yes, especially as mine has got five buttons. YOu could make it modulate<br>different things depending on which button or combo of buttons is pressed.</blockquote><div><br>There are some examples here;<br><a href="http://smelt.cs.princeton.edu/">
http://smelt.cs.princeton.edu/</a><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;">[Quest for Fame V-pick]<br>The game is great fun but the controller is not. It is plugged in the serial
<br>port and only transmits simple pulses when the pick is used. So I&#39;d say it<br>is about as good as a single keydown on the keyboard for control purposes.</blockquote><div><br>Oh. Right. That&#39;s disapointing. I had hoped it would be based on tilt/ inertia sensors.
<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;">[ChucK v.s. modulars]<br>Yes, all timing is auto-synchronized to the sample the way I understand it.
<br>Still ChucK&nbsp;&nbsp;does require rethinking common modular synth designs as you<br>say, in terms of how to implement them.</blockquote><div><br>Exactly. Sticking to &quot;modular tactics&quot; will lead to ugly code and much cpu overhead.
<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;">&gt; back and forth between audio and controll signals tends to be cpu<br>&gt; intensive.
<br>is there a difference? I didn&#39;t know that. I was kinda hoping I could use<br>any audio signal for control or vice versa.</blockquote><div><br>Well, you can if you need to.<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;">
 Which raises questions like, how<br>do you convert between the two and what&#39;s the event rate?</blockquote><div><br>You can convert controll signals (the code you write yourself) to audio using either &quot;step&quot; or &quot;impulse&quot;, both are Ugens you might want to look up. You can get audio-rate values to base conclusions/events/modulations/whatever on by polling 
myugen.last(). The event rate is whatever you make it; it equates directly to the amount of time you advance each loop itteration.<br><br>However; to detect things like edges and zero crossings you&#39;ll need to advance time by just one sample each itteration and loops like that eat a lot of cpu.
<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 think the<br>manual, though it has example code, lacks formalism in the style of say the
<br>K&amp;R C book, of which I&#39;m a big fan.</blockquote><div><br>Fair, but our manual costs less money then that book (in fact it&#39;s free) and hence it has a volunteer maintainer who&#39;s currently bussy with more urgent stuff. To asist in that I started a page on the WIKI to list things that are unclear to people or outdated, missing or downright likely to cause nuclear melt-down or family dramas.
<br><br>If there&#39;s something identifiable that you find confusing or unclear then you are mroe then welcome to join in; anybody can join the WIKI and add pages.<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;">
<br>I see, I&#39;l try something like that out. AS with so many other coding things,<br>the best way to learn is to write and make mistakes, &lt;smile&gt;. But I&#39;ve<br>noticed that as a learner I usually like to start with a good book. In this
<br>case, the manual is far from complete, so looking at the examples is<br>something I&#39;ll have to do eventually.</blockquote><div><br>A book would be nice yes, but that&#39;s far off. I think the closest thing yet is Ge&#39;s accedemic papers that basically attempt to convince that running ChucK is a good idea at all.
<br></div><br>C does have books but C is quite old, proven to be usefull, not widely regarded as likely to explode nor is it -currently- a very experimental sort of thing. Perhaps most importantly; when you confess to using C people don&#39;t look at you attempting to determine wether you are mad. This is all quite unlike ChucK &lt;grin&gt;.
<br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>AH good info,, I think this will get me going, thanks. I read about class<br>files but diddn&#39;t realize I could use the same add operation to include
<br>code.</blockquote><div><br>You can. Adding a file that has a public class to the VM will instantly make that class available to other ChucK programs. In fact you could allways start Chuck using;<br><br>chuck --loop my_class1.ck my_class2.ck my_class3.ck
</div><br>Perhaps through a batchfile, and all your classes would always be there for you to use.<br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>Yes, and you might also want to add the ability not to quantize user input.<br>The Alesis SR-16, whose step editing I already dissed, actually is one of<br>the few drum machines which support both quantized and unquantized input.
</blockquote><div><br>That&#39;s a thing for the future. Considdering the latency that the Windows drivers give I&#39;m quite happy to have implemented realtime input quantisation... This is still good fun, I can now hammer buttons randomly and the output will still be in perfect sync.
<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>Yes, that could work. Another thing I&#39;m going to try at some point is tap
<br>tempo and then the ability to loop a portion of a song when you hit a key,<br>such that you can determine the unit in looping, as musical time. </blockquote><div><br>Go for it!<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&#39;ve<br>noticed that when I use the software based volume control buttons on my<br>laptop, Winamp playback studders in a cool and half-musical way. If only I<br>could sync that and make the process more controllable ...
</blockquote><div><br>Most likely you can controll it using &quot;keyboard repeat rate&quot;, that&#39;s in your Windows keyboard settings.<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;">
&gt; one of my prime demands is that it needs to be usable in the dark,<br>Which is interesting. ONe academic paper I read recently on accessibility<br>said that in addition to aiding say people With no sight, accessibility also
<br>helps in special circumstances like smoky or dark environments. So here we<br>are.</blockquote><div><br>That&#39;s exactly what I was aiming at. Another thing I learned in a interface design class was that people can learn a lot, interface wise, but as soon as they panic this breaks down. The example given was aircraft design. That&#39;s a good example of a highly complicated interface that needs to stay usable under high stress....
<br>&nbsp;</div><br>Kas.</div>