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.