Hi list, A quick question I'll post tonight before replying in the other thread I've started. To gain some experience in ChucK and make it feel more like Reaktor, in terms of modules, I thought I should try implementing some Reaktor modules in ChucK itself. of course, it makes no sense to create something as simple as an audio adder as we have the infix plus binary operator already in the language. So I dug up an ancient Generator module (Generator was the product before they named it Reaktor), and picked a relatively simple example namely a wave made up of series of up and down counts as folows: Quote ancient Generator manual: Multistep Oscillator 4-Ramp Oscillator for 4-ramp waveform with logarithmic pitch control and linear amplitude modulation. The level of each of the breakpoints which are connected by ramps can be set independent of the others. w P: Logarithmic event input for controlling the pitch (oscillator frequency). Value in semitones (69.0 = 440 Hz, but also see DAC Tun). 112 w A: Audio input for controlling the amplitude. The output signal moves between +A and - A. w S1: Event input for controlling the level of the first breakpoint. w S2: Event input for controlling the level of the second breakpoint. w S3: Event input for controlling the level of the third breakpoint. w S4: Event input for controlling the level of the fourth breakpoint. w Out: Audio signal output for the ramp waveform. End quote. Although in this case my aim would be to create a Multistep Oscillator n-Ramp to make it more flexible. In stead of multiple getters and setters I'll create just one with an index parameter, makes life much easier. I read that constructors having parameters are not supported, so I might as well use an initializer method to set parameters after instanciation. I've been looking into ./class/dinky.ck and it claims that one cannot yet inherit from a Ugen, ouch. Is that still true? Well if classes are duck-typed as in Perl or Ruby, i.e. common method names are good enough for polymorphism, then that's not a problem I suppose. I've been trying to grasp how a uGen operates, too, where is it documented thoroughly? The manual says all uGens have certain common parameters. But how should I implement something like: Quote manual: . .chan - (int) - returns a reference on a channel (0 ->N-1) End quote. For my class which should work like a uGen, i.e. what to return and where do I get the object I'm supposed to return? Ideally I'd like to create modules that make no difference between event and audio signals as in a true modular. Howabout modules with multiple inputs. Another thing I'm thinking of creating would be a simple multiplexer named OneOfN which has n inputs and a selectN adress bus. It connects the input addressed by selectN to the output. This is a generalization of the Reaktor modules audio switch 2, 4, 8 and event switch 2, 4, 8. Are such multi in/out modules currently feasible? Do I have to advance time in such a module, as it is a (stateless)combination circuit, not a state machine? Lastly, how do I import my classes in a project ii.e. is there some C:ish preprocessor include syntax or a Java-like classpath environment variable? I find there ar a number of things the manual and a quick glance at the examples doesn't answer adequately. Well, I'm glad we have this list. And sorry to bother you with pretty obvious newbie Qs, I mean if one has ever created an instrument, all or most of these must have been answered already, or else I'm seriously lost, <smile>. Is there a FAQ or archive? -- With kind regards Veli-Pekka Tätilä (vtatila@mail.student.oulu.fi) Accessibility, game music, synthesizers and programming: http://www.student.oulu.fi/~vtatila/
Veli-Pekka Tätilä wrote:
I've been trying to grasp how a uGen operates, too, where is it documented thoroughly? The manual says all uGens have certain common parameters. But how should I implement something like:
Quote manual: . .chan - (int) - returns a reference on a channel (0 ->N-1) End quote.
For my class which should work like a uGen, i.e. what to return and where do I get the object I'm supposed to return? Ideally I'd like to create modules that make no difference between event and audio signals as in a true modular.
the best aproach is to take an existing file like ugen_osc.cpp rename it & the corresponding ugen_osc.h and try to modify it. it is pretty straightforward i think. you'll have to rename the osc_query funktion. and call it in the load_internal_modules in the chuck_compile.cpp file. i started experimenting a little bit with the source yesterday and it was pretty simple to add new ugens.
Howabout modules with multiple inputs. Another thing I'm thinking of creating would be a simple multiplexer named OneOfN which has n inputs and a selectN adress bus. It connects the input addressed by selectN to the output. This is a generalization of the Reaktor modules audio switch 2, 4, 8 and event switch 2, 4, 8. Are such multi in/out modules currently feasible? Do I have to advance time in such a module, as it is a (stateless)combination circuit, not a state machine?
you have to calculate and return each tick/sample. i am still guessing a lot of things but it is not that hard as i thought. best joerg -- http://joerg.piringer.net http://www.transacoustic-research.com http://www.iftaf.org http://www.vegetableorchestra.org/
joerg piringer wrote:
I've been trying to grasp how a uGen operates, too, where is it documented thoroughly? The manual says all uGens have certain common parameters. But how should I implement something like:
Quote manual: . .chan - (int) - returns a reference on a channel (0 ->N-1) End quote.
For my class which should work like a uGen, i.e. what to return and where do I get the object I'm supposed to return? Ideally I'd like to create modules that make no difference between event and audio signals as in a true modular.
Veli-Pekka Tätilä wrote: the best aproach is to take an existing file like ugen_osc.cpp rename it & the corresponding ugen_osc.h and try to modify it. Hmm, so it's the C++ route again. I thought I could create Ugens within chucK itself rather than merely connecting existing modules together and controlling patches. Although I do admit C++ is good for performance, I'd much prefer working with a Java-like high-level language, like ChucK would be, even for things that would be simple in C++.
you'll have to rename the osc_query funktion. and call it in the load_internal_modules in the chuck_compile.cpp file. Thanks for the tips, I'll look into this.
Howabout modules with multiple inputs. Another thing I'm thinking of creating would be a simple multiplexer named OneOfN which has n inputs and a selectN adress bus. It connects the input addressed by selectN to the output. This is a generalization of the Reaktor modules audio switch 2, 4, 8 and event switch 2, 4, 8. Are such multi in/out modules currently feasible? Do I have to advance time in such a module, as it is a (stateless)combination circuit, not a state machine? you have to calculate and return each tick/sample. Oh ok, how is sub-sample resolution handled in C++-code then?
-- With kind regards Veli-Pekka Tätilä (vtatila@mail.student.oulu.fi) Accessibility, game music, synthesizers and programming: http://www.student.oulu.fi/~vtatila/
participants (2)
-
joerg piringer -
Veli-Pekka Tätilä