[chuck-users] chuck ide plans / ideas

[Kassen]

On 1/24/07, tazumi <tazumi at gmail.com> wrote:

the problem is that i am alomst sure that most of that stuff would never
> find its way into mini audicle, because of different reasons..


I do think your ideas touch upon some aspects of ChucK that everybody runs
into to a greater or lesser degree and that could use a carefull look in the
future. I think the code-replacement features in chuck --shell also try to
deal with some of this but from a slightly different angle. For example a
graphical way of adressing those in the Mini would make loads and loads of
sense to me (this idea has been on my mind for a while now).

A few days ago I had to manually write a large-ish (200+ numbers) array to
deal with some non-linearities in a Nord Modular parameter that I wanted to
automate and I certainly agree that there would be benefits to a higer level
way of filling arrays, particularly for large and multi-dimentional ones.
This is of cource asuming a sensible way could be found at all; I'm not so
much into office aplications and their files.



> thats one point, because as i said above: many of the ideas come from a
> very personal way of using chuck. many people won't think that this is
> important at all, but they are very important for me.. so sometimes you will
> have to do things yourself :-)


No, I suspect nearly everyone might agree to this. I imagine nearly everyone
here at least tries to write some of his own instruments. I heard some
especially crazy people here even defined a complete syntax because of
personal ideas on how things should work! ;-)



another point is that things - like for example that plugin idea - are hard
> to explain, and i am pretty sure that at least 50% of the people think "what
> the hell does he want??" or sth. like that while reading the post :-)


Well, I'm not. I think what you are after is somewhat similar to a more
interactive version of Csound's macros for writing large score files, at
least in intention.



because of that I even was not sure if i should write about it at all :-/


I think it's very good that you wrote about this. Clearly you are running
into problems/limitations/inconveniences; if more people have the same
questions we can try to pinpoint the core of the issues and work together at
cooking up solutions. Everybody stands to gain from this.

And, well, if nobody shares the question then you can always go look for a
answer on your own anyway.


  things like that maybe have to be tried out/tested to get the point behind
> it.. Only having some strange abstract description of functionality is not
> enough here :-)


Yes, clearly. It's a very practical sort of issue that's not solved unless
the solution is practical as well.


if it looks cool/usefull, one can decide that its worth the trouble to add
> it to audicle or mini audicle..


I think the main matter might not be the actual code but be in the interface
and implementation, yes. That one will require some deep thought regardless
of what it would get written in.



lets see.. besides all that, i simply have fun doing projects like that..
> it is the same reason why i do music: the result is not the only reason
> for doing it - the way getting there, the process of creating, is sometimes
> even more important / the more satisfying part :-)


 Sounds extremely healthy to me!


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