| Author |
Message |
gbenjamin
Joined: Oct 18, 2008
Posts: 2
Location: Michigan
|
 Posted: Wed Oct 22, 2008 7:38 pm Post subject:
UGen Object Hierarchy
Subject description: A little gripe |
  |
|
I'm writing a class that I essentially want to use as a "performer"--basically I would use a function to tell an instance what UGen it has, and the object would set frequency, gain, etc. on its own according to some rules. This is impossible, as it turns out, because I can't set frequency on a generic UGen since it doesn't have a freq() member.
It would be nice if the UGen hierarchy were such that there was a subclass of "synthesis" UGens so that one could have access to synthesis-specific attributes without actually knowing what type it is in particular.
This is actually for a thesis project, so when I've finished it, I'll be sure to post the paper and the program!
It's been a fun project. ChucK's pattern of "process, advance time, process, etc." is very intuitive. |
|
|
Back to top
|
|
 |
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Thu Oct 23, 2008 2:45 am Post subject:
|
|
|
Why not simply write a "instrument" class, give it a "freq" member function and extend that a few times for the different types of Ugen you want?
I could hack you up a small example later today if you'd like.
_________________
Kassen |
|
|
Back to top
|
|
|
rogan
Joined: Dec 16, 2007
Posts: 83
Location: Urbana, IL
Audio files: 5
|
| Posted: Thu Oct 23, 2008 10:54 pm Post subject:
|
|
|
Has there been any talk about adding a way to check if something has been defined? This is more of a scripting language feature, but I could see it being useful. Then we could do operations like
| Code: |
if ( defined item.freq() ) {
do => something;
}
|
Hmm. At first I could see myself doing this all the time, but exactly how useful would this actually be for people? I could see it being nice if we were processing text from files. |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Fri Oct 24, 2008 3:07 am Post subject:
|
|
|
| rogan wrote: | | Has there been any talk about adding a way to check if something has been defined? |
Hmmmm. I think this clashes with the strong typing, stylistically.... still with a VM, compiler and parser that share namespace and everything *meant* to add to existing structures, structures that may not be defined by us (but instead by our friend who's computer is linked to our VM as well) it could make some sense.
I feel this is part of a larger cluster of issues, including the possibility of a larger granularity in updating running structures that should be tackled in one coherent go, not as separate problems. ChucK isn't a scripting language, our problems are different and so should the solutions be (even if I'm in favour of stealing where it makes sense).
Anyway, here I'd define a class called "instrument" with a set of known parameters and extend that to classes that may be just a wrapper for a single UGen (like Mandolin) and others that may be a small set of UGens (like a osc, a filter and a ADSR), and have all of those share the same members. This would be a bit of work but once you have it wou can build up a library and re-use that many times.
_________________
Kassen |
|
|
Back to top
|
|
|
radarsat1
Joined: Mar 14, 2008
Posts: 85
Location: Montreal
|
| Posted: Fri Oct 31, 2008 10:19 am Post subject:
|
|
|
Many of the physical modelling UGens inherit from the StkInstrument class which does indeed provide a common "freq" for all subclasses.
However, you're right that it would be cool to have this go higher up in the hierarchy.
The hierarchy of UGens is based more on how they are grouped in libraries (STK for instance) rather than a real logical organization.
The dynamic approach would be cool too (checking if .freq exists), but ChucK is not a dynamic language like JS or Python, so it's not going to happen. |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Fri Oct 31, 2008 11:30 am Post subject:
|
|
|
| radarsat1 wrote: |
The hierarchy of UGens is based more on how they are grouped in libraries (STK for instance) rather than a real logical organization.
|
This is a good point. Now that we have at least a start for user contributed UGen's we could expect more "instrument" type UGens to appear. It wouldn't hurt at all to have a look at the hierarchy at this point. Perhaps it would make sense to have a "instrument" object in there with .freq(), .noteOn() and .noteOff() in addition to the regular UGen object.
I think we need a plan there and somebody in charge of what UGen's are worthwhile to include in the main build as well as a procedure to submit user-generated UGen's (UGenUGen's?).
The SC people have something like this and it seems to work quite nicely (on a social level as well as a functional one). Can we steal what they are doing? We need Ge's opinion on this, of course we would still go forward without him but I foresee a mess down that route.
_________________
Kassen |
|
|
Back to top
|
|
|
radarsat1
Joined: Mar 14, 2008
Posts: 85
Location: Montreal
|
| Posted: Fri Oct 31, 2008 3:20 pm Post subject:
|
|
|
| Kassen wrote: | | This is a good point. Now that we have at least a start for user contributed UGen's we could expect more "instrument" type UGens to appear. It wouldn't hurt at all to have a look at the hierarchy at this point. Perhaps it would make sense to have a "instrument" object in there with .freq(), .noteOn() and .noteOff() in addition to the regular UGen object. |
Actually that's pretty much exactly what StkInstrument provides. The question is whether "instrument" is really a good name for it. SinOsc for example also has .freq, but it's not really an instrument..
Maybe 'frequency-based generator' is a better name, however you want to summarize that into a single word. But unfortunately I think this is whether the hierarchical approach breaks down, and a more dynamic solution is called for. I don't really think that from any general point of view we can come up with a top-down hierarchy for UGens. However maybe there's still some virtue in doing the best we can with what we have, and from a more pragmatic point of view at least building the hierarchy according to what properties objects actually have.
| Kassen wrote: | I think we need a plan there and somebody in charge of what UGen's are worthwhile to include in the main build as well as a procedure to submit user-generated UGen's (UGenUGen's?).
The SC people have something like this and it seems to work quite nicely (on a social level as well as a functional one). Can we steal what they are doing? We need Ge's opinion on this, of course we would still go forward without him but I foresee a mess down that route. |
Personally I'm not a fan of the "externals" approach used by Pd for example, because I think it brings along with it a lot of run-time problems related to search paths, etc. I prefer the approach of just developing centrally a really good database of useful UGens and integrating them into the core environment. In other words, I agree with you here, that someone should help try to build them in to ChucK.
I'd actually be interested in the idea of building an "extended ChucK" fork which is community-based, where we can integrate custom UGens into the main ChucK executable. The 'official' ChucK project could then take what they want from the extended version. This kind of two-tier approach is quite good I find, since on the one hand it adds a layer of peer review, and on the other hand takes a lot of work off the backs of the core developers in terms of integration.
Such a project could be started quite easily actually by just sticking up a clone of the CVS repository on a public server. Let's kick the idea around a bit and then maybe take some action. |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Fri Oct 31, 2008 4:15 pm Post subject:
|
|
|
| radarsat1 wrote: |
Actually that's pretty much exactly what StkInstrument provides. The question is whether "instrument" is really a good name for it. SinOsc for example also has .freq, but it's not really an instrument.. |
I know... but clearly something that was build by you or me isn't a "STK" instrument yet still may have those member functions and a similar purpose.
I'd also say just basing a class on a ".freq()" parameter does seem a bit thin to me. All of the STKInstrument ones are more or less self-contained sound-sources capable of melodic play. So far none of them support audio input. That's different from -say- SinOsc or BPF, both of whom have a .freq() parameter.
| Quote: |
I don't really think that from any general point of view we can come up with a top-down hierarchy for UGens. However maybe there's still some virtue in doing the best we can with what we have, and from a more pragmatic point of view at least building the hierarchy according to what properties objects actually have. |
I'm inclined to agree. I think "Instrument" is a loaded word, I find it a bit hard to say -for example- "LiSa isn't a instrument". Practically speaking I think I'm inclined towards having the capability of writing ChucK code that extends Ugen yet can also belong to arbitrary classes. This would leave it up to the programmer to define what (s)he feels is a "instrument" and how such a thing should be controlled. Leaving that question open to interpretation seems very ChucKian to me, but we could use more extensive ways of answering the question.
| Quote: |
I'd actually be interested in the idea of building an "extended ChucK" fork which is community-based, where we can integrate custom UGens into the main ChucK executable. |
Great! I was going to suggest forming a mob with pitchforks that would "persuade" you to "volunteer" for this position ;¬). You seem perfect for it.
| Quote: | The 'official' ChucK project could then take what they want from the extended version. This kind of two-tier approach is quite good I find, since on the one hand it adds a layer of peer review, and on the other hand takes a lot of work off the backs of the core developers in terms of integration.
Such a project could be started quite easily actually by just sticking up a clone of the CVS repository on a public server. Let's kick the idea around a bit and then maybe take some action. |
I agree with the principle, I will also agree with this specific strategy assuming Ge is fine with it. As a overall plan it sounds great to me, all of the tinkering and only a small percentage of the risk to the main branch. We could still use a better system to get peer-reviewed code into the main build; I think we can by now safely say ASIO has been peer-reviewed, for example.
Anyway If you will be the chief builder for this I'd like to apply for a position as a senior breaker and jr-assistant builder. We'll need some more breakers and builders and anything that doesn't get broken can be dusted off and send to Stanford. It's somewhat non-ChucKian to test things before release but at least we'll have developers that aren't too burdened by a excess knowledge of C++ so I'm sure it'll still be exciting.
I'd like to propose we call this branch "Wolfman". this would fit in with Dracula and Frankenstein and reflect how it would be about transformation as well as potentially hairy.
There will be a honorary prize for the first person to document using this branch in a live performance to more then 25 people. Custom UGens must be used. Bonus points for having them fail in a artistically interesting way.
_________________
Kassen |
|
|
Back to top
|
|
|
radarsat1
Joined: Mar 14, 2008
Posts: 85
Location: Montreal
|
| Posted: Sat Nov 01, 2008 11:18 am Post subject:
|
|
|
| Kassen wrote: | | Great! I was going to suggest forming a mob with pitchforks that would "persuade" you to "volunteer" for this position ;¬). You seem perfect for it. |
I like the idea for sure. I have to admit the only reason I seem to have time to work on (or with) chuck is because I seem to be honestly obsessed with it. When it comes down to it, it can't be first priority for me, but I definitely like the idea of having available a public development process which doesn't require permission from a university, so I guess I would be wiling to pitch in in this respect.
Maintaining a community project can start to bite into one's schedule quite easily, I'm afraid, but seeing as there's only a few people interested in the development side of things, it doesn't look at the moment as if it would be _too_ overwhelming.
| Kassen wrote: | | I agree with the principle, I will also agree with this specific strategy assuming Ge is fine with it. |
As long as we don't claim that it's the official chuck build, I think Ge won't have a problem with it. He'll probably appreciate the effort in taking work off his hands actually.
| Kassen wrote: | | As a overall plan it sounds great to me, all of the tinkering and only a small percentage of the risk to the main branch. We could still use a better system to get peer-reviewed code into the main build; I think we can by now safely say ASIO has been peer-reviewed, for example. |
Exactly, I'd love to set up an automated build system to provide nightlies including ASIO builds, etc.
| Kassen wrote: | | I'd like to propose we call this branch "Wolfman". this would fit in with Dracula and Frankenstein and reflect how it would be about transformation as well as potentially hairy. |
good name. :) i like "the blob" too, as it reflects the idea of consuming everyone's contributions, and constantly changing shape.
| Kassen wrote: | | There will be a honorary prize for the first person to document using this branch in a live performance to more then 25 people. Custom UGens must be used. Bonus points for having them fail in a artistically interesting way. |
okay, i'll let you take care of organizing the jury. :) |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Sat Nov 01, 2008 2:38 pm Post subject:
|
|
|
| radarsat1 wrote: |
I like the idea for sure. I have to admit the only reason I seem to have time to work on (or with) chuck is because I seem to be honestly obsessed with it. When it comes down to it, it can't be first priority for me, but I definitely like the idea of having available a public development process which doesn't require permission from a university, so I guess I would be wiling to pitch in in this respect. |
Yeah, I know all about being obsessed with ChucK... and yes, a process outside of the University world could be very healthy for ChucK (and for you and me, of course).
| Quote: |
Maintaining a community project can start to bite into one's schedule quite easily, I'm afraid, but seeing as there's only a few people interested in the development side of things, it doesn't look at the moment as if it would be _too_ overwhelming.
|
We need to make sure it scales well and we have a clear scope. Once we go from this small tutorial to people trying their hand at this you wouldn't need to see anything until there are UGens that at least run; that's all distributed. Then we can test but that's distributed already as well. As long as we don't slide away from the goal of adding UGens and because of the extremely modular nature of UGens I don't think it need demand that much time.
| Quote: |
As long as we don't claim that it's the official chuck build, I think Ge won't have a problem with it. He'll probably appreciate the effort in taking work off his hands actually. |
Yeah, I think so. What I meant is that we need to make sure we can submit what we come up with to the main build with as little work for him as possible. Right now Ge's time is one of the main bottlenecks in ChucK development, I think. Distributing load like this seems like a good plan, unless it would create overhead for him.
| Quote: |
Exactly, I'd love to set up an automated build system to provide nightlies including ASIO builds, etc. |
Cool! Do we have space for that? Once you have a dir of ChucK source that compiles pluging it into a MiniAudicle and having it build is trivial as well.
| Quote: |
good name.  i like "the blob" too, as it reflects the idea of consuming everyone's contributions, and constantly changing shape.
|
That's a better one, I love it. It will also leave space to later evolve into "The Swarm" or other references to "distributed monsters".
| Quote: |
okay, i'll let you take care of organizing the jury. |
That would be bad as I intend to have a go at winning, of course! :¬) This is too crazy to resist!
_________________
Kassen |
|
|
Back to top
|
|
|
rogan
Joined: Dec 16, 2007
Posts: 83
Location: Urbana, IL
Audio files: 5
|
| Posted: Sat Nov 01, 2008 6:45 pm Post subject:
|
|
|
I'm on board. This sounds great. I can already think of a few things that I'd like to take a crack at:
1. Exponential Envelope. You can write exponentials as a series, so this should be easy to implement as a sample-by-sample function.
2. Add memory management to SndBuf. This isn't my strong point, but I think it would add a huge variance to what you can do with chuck. I can imagine dj-ing with chuck if it didn't soak up all my memory loading huge wavs.
Oh, and I think it would be definitely cool to have the ability to load UGens as modules. I think it would prevent chuck from becoming bloated, and it would be a great way to share code.
Just some thoughts. |
|
|
Back to top
|
|
|
radarsat1
Joined: Mar 14, 2008
Posts: 85
Location: Montreal
|
| Posted: Sun Nov 02, 2008 8:07 pm Post subject:
|
|
|
| Kassen wrote: | | Yeah, I think so. What I meant is that we need to make sure we can submit what we come up with to the main build with as little work for him as possible. Right now Ge's time is one of the main bottlenecks in ChucK development, I think. Distributing load like this seems like a good plan, unless it would create overhead for him. |
I'll be blunt here and just mention that if I were to maintain such a project, one thing I'd insist on is using git. I wouldn't want to unnecessarily introduce an "advanced" tool like this for no reason, but there is simply no better tool for this kind of thing.
What it allows you to do is to track the main CVS tree in a branch, and then maintain another branch which is essentially a set of patches on top of the upstream branch. Other people can then clone from you, and when they've got something they submit a patch by email, or publish their git repo and you can grab from it. Everything stays synchronized and authorship even gets preserved, and there's no need to deal with handing out write permissions or maintaining a proper list of developers.
Then, for submitting things back upstream, you can generate patches against the upstream tree automatically, and when they get integrated, you can resynchronize and rebase your branch off the new upstream.
If any of that doesn't mean anything to you, don't worry.. all it says is, git makes distributed work very possible, very organized, and even, once you learn the tool, pretty easy.
Frankly I think it's a tool worth learning all in itself. There's a lot of commands, but only a small set of commands them are needed to start with. (I mainly use "diff", "apply", "add", "commit", "push" and "pull" on a daily basis. Not much else.)
| Kassen wrote: | | Cool! Do we have space for that? Once you have a dir of ChucK source that compiles pluging it into a MiniAudicle and having it build is trivial as well. |
I was looking for space today actually. The thing is, it's not at all hard to find space to host a git repository (i have an account on gitorious.org for example), but it's a little harder to find a place to make a little website and put up compiled binaries. I had a look at codehaus.org which looks alright, or there's always sourceforge or google code as well. |
|
|
Back to top
|
|
|
rogan
Joined: Dec 16, 2007
Posts: 83
Location: Urbana, IL
Audio files: 5
|
| Posted: Sun Nov 02, 2008 8:42 pm Post subject:
|
|
|
| glt sounds pretty handy and would allow very modular code production. I'd be down for that. |
|
|
Back to top
|
|
|
|
Forum index » DIY Hardware and Software » ChucK programming language
FAQ
Calendar
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Chat Room
