Author |
Message |
charley
Joined: Sep 03, 2008 Posts: 8 Location: San Francisco, CA
|
Posted: Wed Sep 03, 2008 4:07 pm Post subject:
Custom Ugen |
|
|
If I'm understanding ChucK's design correctly the idea is to eliminate the need to build modules/functions in other languages so that everything is written natively.
But, it seems that in order to do things natively, I have to develop everything using ChucK's prebuilt Ugen and Uanas. What if I want to develop my own Ugen, for example a neural net based adaptive filter?
I've seen some examples here where folks have patched together sample level functions in ChucK but it seems a bit of a hack to me. Maybe I just haven't gotten the full 'ChucK' principle yet.. ?
Has there been any talk to enable the development of custom Ugens directly in ChucK? For example, wouldn't it be cool if SinOsc was written directly in ChucK instead of being locked away and inaccessible to ChucK users?
Or maybe this is already possible and I just don't understand it yet.. |
|
Back to top
|
|
|
radarsat1
Joined: Mar 14, 2008 Posts: 85 Location: Montreal
|
Posted: Wed Sep 03, 2008 5:24 pm Post subject:
|
|
|
i agree that it would be cool to be able to more easily construct Ugens in ChucK. The problem is that the chuck compiler produces VM instructions, not native code. The main advantage of Ugens over doing sample-level processing in chuck is basically just efficiency. (Any long-running sample-level chuck code will blow your CPU usage to hell)
So yeah, the chuck principle is basically to do as many cool things as you can with the Ugens provided, and use chuck code to glue it together, with sample-accuracy when necessary, and take care of the logic level stuff. If you want to build a Ugen you have to currently do it in C++.
I was thinking it would be cool to write a chuck-to-C compiler that produces Ugens, but it would be a big job. In the mean time a how-to-make-a-Ugen tutorial would be great. I would like to work on it some time but currently don't have time for it.
It's not obvious because of all the macros and such used in the chuck source that you need to become familiar with. |
|
Back to top
|
|
|
charley
Joined: Sep 03, 2008 Posts: 8 Location: San Francisco, CA
|
Posted: Wed Sep 03, 2008 11:03 pm Post subject:
|
|
|
I wonder if there's a way to think about the design of the language (ChucK) to construct lower level 'ugen' functions.
Does anyone have any knowledge of developing ugens in c/c++. I would assume that the current ugens are linked into the ChucK compiler/runtime and can't be referenced as an external at runtime... Yes? So then, the only way to add Ugens now is to recompile the entire ChucK package? Is this correct?
Are Ugens/Uanas represented by VM bytecode or are they compiled c/c++ called externally from the Virtual Machine? I guess I should read more on the dev docs, but I can't seem to find them :0
What are .ckx external plug-in files? I noticed a reference to them ont he developer's page..
BTW, I'm not complaining.. I absolutely love the ChucK architecture and the idea behind Strongly-Timed program flow.. Incredible! |
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004 Posts: 7678 Location: The Hague, NL
G2 patch files: 3
|
Posted: Thu Sep 04, 2008 3:35 am Post subject:
|
|
|
Yes, if you want to add or change a Ugen then that means doing so in C/C++ and recompiling ChucK. Changing a existing one isn't so hard, basically it's a class with some member functions (to set frequency or whatever) and a "tick" function that tells the Ugen how to calculate it's next sample. Mostly these are quite readable. Creating a new one is more work and would involve figuring out where all those things are mentioned, which seems to be rather a lot of places and is beyond me. There are comments in the source but I couldn't find anything like "this is what's going on on the larger structural level".
There have been plans for a long time to have a sort of toolkit for writing Ugens and while everybody agrees this would be great it hasn't been very high priority and seems to be stuck in the planning stage. (I think .ckx files are mostly a nice dream at this stage). Other things like fileIO and garbage collection are higher on the list, probably deservedly so.
Radarsat here has been talking lately about a tutorial on writing Ugens and I hope he finds the time for this. I wouldn't mind a bit of recompiling to get a nice new Ugen. Our friends/colleagues/mortal enemies over at SC have some interesting looking ones that might be nice to borrow as well... _________________ Kassen |
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004 Posts: 7678 Location: The Hague, NL
G2 patch files: 3
|
Posted: Thu Sep 04, 2008 3:48 am Post subject:
|
|
|
radarsat1 wrote: |
I was thinking it would be cool to write a chuck-to-C compiler that produces Ugens, but it would be a big job. |
Yeah... and the CKtoC compiler would need to demand a certain writing style. You'd need to outlaw things like sporking, it would need to know what function is supposed to be the "tick" and that function is probably going to be the only one that can advance time, and then only by samp. What would still be allowed would probably look so much like C that perhaps it wouldn't be worth the effort.
The specifications for what would and wouldn't be legal input for this would probably come down to a description of the Ugen format and at that point I think we could replace this whole compiler with a list of "differences between C and CK relevant to writing Ugens" in a nice and friendly format. _________________ Kassen |
|
Back to top
|
|
|
charley
Joined: Sep 03, 2008 Posts: 8 Location: San Francisco, CA
|
Posted: Thu Sep 04, 2008 3:52 pm Post subject:
|
|
|
I can see in the source code (chuck_compile.cpp) where the compiler initializes the base classes (which include ugen and uana).. There is a call to type_engine_init (in chuck_type.cpp) and then a further call to init_class_ugen (chuck_lang.cpp)
It looks like the magic stuff happens in type_engine_import_class_begin (and associated...).. From this perspective, it looks fairly straightforward to add your own ugens (or any base class) for that matter BUT it would have to be linked in at compile time to the main chuck.exe. Easy to do, but then we end up with disparate versions of chuck by different developers who each have their own base classes or ugens..
A second solution would be to add dynamic linking ability to an external dll to add any new base class to the system.. I'm guessing this is the idea behind .ckx files.. This is probably the easiest and most convenient in the short term.. With this solution, we'd end up with a community driven set of plugins to extend ChucK easily.. The downside is that plugins destabilze the system and spread the propability of a system crash across many developers efforts..
A third solution would be to *inline* c/c++ code inside of chuck with some special wrapper.. This would require the c/c++ compiler to be present at run time though so it's probably not that feasible..
A Fourth solution would be to create special ChucK instructions that compile to native machine code and could be linked at runtime.. This could be a very limited instruction set just for simple sample manipulation.. Native Instruments does this (sort-of) with Reaktor, where you can work at a high-level module interconnection mode, or you can drop down into a more 'machine-code' like syntax (core).... |
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004 Posts: 7678 Location: The Hague, NL
G2 patch files: 3
|
Posted: Thu Sep 04, 2008 4:09 pm Post subject:
|
|
|
charley wrote: |
A second solution would be to add dynamic linking ability to an external dll to add any new base class to the system.. I'm guessing this is the idea behind .ckx files.. |
I think so because not everybody is on Windows (I'm typing this on Linux, for example). There are questions there.
Still, with some level of quality control we could merge especially useful Ugens into the main release. I think that's a especially interesting goal; there is nothing wrong with wanting custom Ugens but right now we can freely exchange ChucK code (excepting MiniAudicle graphical elements and MacBook movement sensors) between Linux, OSX and Windows which I feel is a great strength we should take care to preserve.
Another thing is that I suspect I could -given some time- make a nice Ugen or two but I'm not at all sure I could make something that couldn't be improved on (in ways useful to me as well) by other people... _________________ Kassen |
|
Back to top
|
|
|
radarsat1
Joined: Mar 14, 2008 Posts: 85 Location: Montreal
|
Posted: Sat Sep 06, 2008 7:29 pm Post subject:
|
|
|
I just noticed the following comment in the examples/class/dinky.ck file:
Code: | // NOTE: in a future version of chuck...
// this class will be able to extend UGen |
interesting |
|
Back to top
|
|
|
Inventor
Stream Operator
Joined: Oct 13, 2007 Posts: 6221 Location: near Austin, Tx, USA
Audio files: 267
|
Posted: Fri Sep 19, 2008 6:25 pm Post subject:
|
|
|
Yes, also in the table of contents of the language specification, the final subsection of the "unit generators" section says: "creating (coming soon)". Of course, it has said that for at least a year now, but at least the goal is clearly stated. _________________ "Let's make noise for peace." - Kijjaz |
|
Back to top
|
|
|
|