[chuck-users] Keyboard Stuff

[Hans Aberg]

On 17 Apr 2009, at 22:22, Kassen wrote:

>> The problem is that it might not be possible, if some keys are used  
>> for playing and other for manipulating data.
>
> I don't think there will be a issue with that. Your program would  
> have its data and its structure for playing sounds and both would be  
> affected by a single shred that would parse the keyboard. That sort  
> of thing is quite possible and a fairly normal type of structure for  
> a ChucK program.

ASCII would not be needed at this point. And I could think of  
workarounds: using escape sequences or multiple keyboards. I was think  
more in general: it's not good having these limitations.

>> But as for the voice assignment problem, perhaps there might be the  
>> need of some structure handling it. Hope for the future :-).
>
> I'm certain you can do way better than hope. You'll need to define  
> for yourself what voice assignment means to you here. From there on  
> it's a matter of translating that definition to formal code.  
> Personally I think it's a good thing that ChucK has no inherent idea  
> of what voice assignment and cycling mean as that means we get to  
> figure out what we need in our specific situation. The developers  
> can't foresee what any individual programmer might want or need (I'm  
> quite certain they are already very aware of that...)

To begin with, support might be in a combination of library and  
program. It's more like it's nice to have a feature like say GC  
(garbage collecting) rather than having to implement it on your own.

If there was a simple way, if that now was needed, to just being able  
to add generators and the program could sort out which ones were  
needed for the sound output, would that not be great?

> > I was only hoping not having to program so much...
>
> Sorry :¬).
>
> I fear you're going to have to program a bit. It's not all *that*  
> much and 90% is coming up with a good plan.

I have done a lot of programming in the past. But I think a  
programming language that forces you trying to find workarounds rather  
than focusing on the task ahead is flawed.

   Hans