electro-music.com   Dedicated to experimental electro-acoustic
and electronic music
 
    Front Page  |  Radio
 |  Media  |  Forum  |  Wiki  |  Links
Forum with support of Syndicator RSS
 FAQFAQ   CalendarCalendar   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   LinksLinks
 RegisterRegister   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in  Chat RoomChat Room 
 Forum index » DIY Hardware and Software » ChucK programming language
Custom Ugen
Post new topic   Reply to topic Moderators: Kassen
Page 1 of 1 [9 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
Author Message
charley



Joined: Sep 03, 2008
Posts: 8
Location: San Francisco, CA

PostPosted: Wed Sep 03, 2008 4:07 pm    Post subject: Custom Ugen Reply with quote  Mark this post and the followings unread

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.. Very Happy
Back to top
View user's profile Send private message
radarsat1



Joined: Mar 14, 2008
Posts: 85
Location: Montreal

PostPosted: Wed Sep 03, 2008 5:24 pm    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message
charley



Joined: Sep 03, 2008
Posts: 8
Location: San Francisco, CA

PostPosted: Wed Sep 03, 2008 11:03 pm    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message
Kassen
Janitor
Janitor


Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3

PostPosted: Thu Sep 04, 2008 3:35 am    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message Send e-mail Visit poster's website
Kassen
Janitor
Janitor


Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3

PostPosted: Thu Sep 04, 2008 3:48 am    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message Send e-mail Visit poster's website
charley



Joined: Sep 03, 2008
Posts: 8
Location: San Francisco, CA

PostPosted: Thu Sep 04, 2008 3:52 pm    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message
Kassen
Janitor
Janitor


Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3

PostPosted: Thu Sep 04, 2008 4:09 pm    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message Send e-mail Visit poster's website
radarsat1



Joined: Mar 14, 2008
Posts: 85
Location: Montreal

PostPosted: Sat Sep 06, 2008 7:29 pm    Post subject: Reply with quote  Mark this post and the followings unread

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 Wink
Back to top
View user's profile Send private message
Inventor
Stream Operator


Joined: Oct 13, 2007
Posts: 6221
Location: near Austin, Tx, USA
Audio files: 267

PostPosted: Fri Sep 19, 2008 6:25 pm    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic   Reply to topic Moderators: Kassen
Page 1 of 1 [9 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
 Forum index » DIY Hardware and Software » ChucK programming language
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Forum with support of Syndicator RSS
Powered by phpBB © 2001, 2005 phpBB Group
Copyright © 2003 through 2009 by electro-music.com - Conditions Of Use