Hello List, i was using chuck very much in the last few month.. and - as you all know - you always want to have some extra features (that are sometimes very special), some stuff that fits exactly to your needs.. So i decided to start an own Project, an alternative chuck environment.. mainly to have the features of my dreams. anyway, as some other people might be interested, i would like to introduce and describe this project here, and would love to hear what others think about those ideas/plans. actually they are more than plans by now, as maybe 50-60% is already finished for a first basic usable version... the main components are of course basic stuff like a source editor with add/replace/remove shred functions or a lists of the sporked shreads. (Nothing you cant do with mini audicle so far..) There will be no direct connection between the programm and chuck. once chuck is started, all interaction will be done using osc messages - start/stop shreds, keeping the list of running shreds etc.. then there are these special features - very often I do pattern-oriented / loop based stuff when i use chuck. my intention is to create some helping features for that. for example i want to have something like code plugins - a feature that writes some code for you.. mainly they should assist you in tasks that are very basic and can be used in many situations, but need a lot of code writing or are bad to handle.. Its hard to explain in general, so look one example: I often create patterns or sequences using array data. so some typical chuck code looks like this: BlitSaw osc => LPF filt => dac; [ 44, 54, 44, 54, 54] @=> int note; [ 0.5, 0.5, 0,5, 0.25, 0.25] @=> float length; [8000, 12000, 8000, 12000, 12000] @=> float freq; int actual = 0; while(1) { playnote (note[actual], length[actual], freq[actual]); actuall ++; // if (actual > 5) 0 => actual; .. and so on... } this plays a simple little sequence.. Now what i like to do is create a 'Table' or 'Array' Plugin. It will have a user interface that provides a table (like for example in excel) where you can enter your data. The table (columns etc) can be defined by the user - in this case i would create a table with 3 columns, like this: ----------------------------------------- | note | length | freq | ----------------------------------------- | 44 | 0.5 | 8000 | ----------------------------------------- | 54 | 0.5 | 12000 | ----------------------------------------- | 44 | 0.5 | 8000 | ----------------------------------------- | 54 | 0.25 | 12000 | ----------------------------------------- | 54 | 0.25 | 12000 | ----------------------------------------- so you can enter your values in a more easy and comfortable way.. extra features like select multiple cells / copy and paste etc. would make life much easier.. when sporking that file, the plugin will write code that creates the arrays to your file.. the plugin could also write some additional code that creates for example an osc receiver with an array updating function.. so while the shred is running, and you change the value of a cell, the plugin sends an update osc message to the shred, which updates the changed array element immediately.. so you change sequences (or anything that uses data stored in arrays) without stopping or replacing the shred.. (all that done by the pugin, you just have to create a table, enter data, and user that data in your code). Also, you can do it the other direction: if you update array elements using a function that sends a osc message back to the program (provided the plugin ) the table will be updated.. One way to keep / store data generated from within chuck.. i know some people asked about sth like that.. Just one of many ideas.. besides those plugins there will be some other basic components like a file browser, with sample preview function (as i also often use samples) the preview function would do nothing more than create some code like: sndbuf buf => dac; "mysample.wav" => buf.read; buf.length => now; then the plugin would write that code to a temporary file and sporks it.. So many stuff could be done which are very easy to implement, by just generating some code and let chuck do the work :-) As the Program mainly consists of UI stuff and no realtime / time critical stuff is needed, it is written in .Net, i know some people will not like that but it is perfect for those tasks.. And if some other people using linux or osx are interested, let me know, then i would keep in mind to only use parts of the framework that are impelementes in mono too, which i didn't look after so far.. I really would love to hear some opinions about the ideas.. and i hope i can come up with a first version soon.. -- tazumi
I really would love to hear some opinions about the ideas.. and i hope i can come up with a first version soon..
I think it's great! I think it's wonderfull that you pinpoint what you want, then set out to create it. I'd love to see, hear and perhaps try the results. I'd also love to hear about your experiences creating this and how it relates to how you make music. Personally I think I would be preferable to have a big list of all the features people are looking for in these development platforms and see wether we can crystalise those down to some additions to the Mini Audicle, perhaps by having a few people add to it (obviously under Spencer's watchfull eye) because now we have a fair amount of these and it seems to me that the total amount of efford spend now is larger then it should be if there would be more cooperation and a more centralised discussion about what people want and why. This is easy for me to say since I don't speak C and so I'm not realy in a position to add to such a project but that's what it looks like for me. Perhaps it's inevitable that some of this scattering happens since the idea behind ChucK faciliates a very personal way of dealing with music/sound/instruments and so there might be a need for very personal tools; this might also be a good and positive thing considdering the state of mainstream electronic instruments. Just my perspective, Kas.
wether we can crystalise those down to some additions to the Mini Audicle
Hi,
yes i know exactly what you mean.. i thought about that too..
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..
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 :-)
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 :-)
because of that I even was not sure if i should write about it at all :-/
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 :-)
so maybe this project also can also be seen as a test application for ideas
- like i said, in .net it is really easy to implement things, especially if
they need a lot of gui stuff.. i did not really do very much c or c++
programming, but i think it needs a lot of work/time there, so try out
things is not that easy..
if it looks cool/usefull, one can decide that its worth the trouble to add
it to audicle or mini audicle..
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 :-)
g- tazumi
2007/1/23, Kassen
I really would love to hear some opinions about the ideas.. and i hope i
can come up with a first version soon..
I think it's great! I think it's wonderfull that you pinpoint what you want, then set out to create it. I'd love to see, hear and perhaps try the results. I'd also love to hear about your experiences creating this and how it relates to how you make music.
Personally I think I would be preferable to have a big list of all the features people are looking for in these development platforms and see wether we can crystalise those down to some additions to the Mini Audicle, perhaps by having a few people add to it (obviously under Spencer's watchfull eye) because now we have a fair amount of these and it seems to me that the total amount of efford spend now is larger then it should be if there would be more cooperation and a more centralised discussion about what people want and why. This is easy for me to say since I don't speak C and so I'm not realy in a position to add to such a project but that's what it looks like for me.
Perhaps it's inevitable that some of this scattering happens since the idea behind ChucK faciliates a very personal way of dealing with music/sound/instruments and so there might be a need for very personal tools; this might also be a good and positive thing considdering the state of mainstream electronic instruments.
Just my perspective, Kas.
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-- tazumi
On 1/24/07, tazumi
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.
participants (2)
-
Kassen -
tazumi