The ftgenonce lookup happens only at i-rate. Most of time, there is
of thousands of k-rate invocations. Furthermore, the lookup is by
binary search and should be quite efficient. Not all ftable arglists
> I like this example a lot, it makes it a lot easier to do things like
> reverb without putting it in an instrument. But as a programmer I wonder
> immediately if using these strings is efficient; looking up a string is
> slower than looking up a number; but maybe this is taken care of when
> compiling the orchestra and score.
>
> After reading Victors article in the latest CSound journal, I thought
> about writing the core of instruments in a UDO, so it is easier to use
> it with both MIDI parameters and volume+pitch, by having a simple
> instrument that transforms MIDI parameters into volume and pitch and
> calls the UDO with these. But you could do the same with the mechanism
> you propose here.
>
> Mark
>
> Jacob Joaquin wrote:
>> I built a prototype in python. It's about as barebones and fugly as it
>> gets,
>> but it works.
>>
>> I want to briefly describe what this prototype does. Instead of creating
>> instrs in the orchestra, I created classes. Writing a class is nearly
>> identical to writing an instr. A class by itself does nothing. An instr
>> must be created from a class for it to be useful. Multiple instrs can be
>> created from the same class, with each instr being assigned its own unique
>> instr number. Classes support optional arguments, with the values of the
>> arguments being assigned when instrs are created.
>>
>> In the examples listed near the bottom of this post, I designed the
>> classes
>> so that the optional arguments are the names of chn input and output
>> busses.
>> This allowed me to patch instrs as I create them, instead of hardwiring
>> them
>> directly inside of instr blocks.
>>
>> The first example is fairly straight forward. The Basic class, when
>> created, generates an enveloped sine wave, and is written to the chn buss
>> "basic_1". The instance of MonoOut taps "basic_1" and sends it to the out
>> opcode. The final class, Clear, is used to clear the chn buss "basic_1"
>> so
>> that feedback does not occur. This won't be an issue once inlet/outlet
>> opcodes are released as part of a future version of Csound.
>>
>> Example 1 before being processed:
>>
http://www.thumbuki.com/csound/files/mailinglist/CsoundClassEarlyPrototype/basic.csd>>
>> Example 1 after being processed (Csound can render this):
>>
http://www.thumbuki.com/csound/files/mailinglist/CsoundClassEarlyPrototype/basic_realized.csd>>
>>
>> The second example builds off the first, and demonstrates how multiple
>> instances of the same class can be built. Two instances of Basic2 and
>> MonoVerb are created, with each having its own unique instr number and
>> unique chn buss input/output names.
>>
>> Example 2 before being processed:
>>
http://www.thumbuki.com/csound/files/mailinglist/CsoundClassEarlyPrototype/fx_example.csd>>
>> Example 2 after being processed (Csound can render this):
>>
http://www.thumbuki.com/csound/files/mailinglist/CsoundClassEarlyPrototype/fx_realized.csd>>
>>
>> You can download all the files here, including the python file that
>> preprocesses the classes:
>>
http://www.thumbuki.com/csound/files/mailinglist/CsoundClassEarlyPrototype.zip>>
>>
>> I'll keep working on this in my spare time. I'm going to incorporate it
>> into my CSD python package, and put everything up at sourceforge or google
>> code sometime in the next couple of weeks. I'll keep everyone posted.
>>
>> Best,
>> Jake
>>
>>
>>
>> Jacob Joaquin wrote:
>>
>>> Reusing a Csound instrument in a new score typically involves copying and
>>> pasting the instrument into a new orchestra. Once pasted, the user, more
>>> often than not, must make modifications to the instrument in order for it
>>> to work in its new environment. Sometimes it is only a matter of
>>> changing
>>> the instrument number. Other times, f-tables have to be ported and
>>> renumbered as well. If there are software busses involve, such as zak,
>>> then modifications suddenly become a minor rewrite of the instrument.
>>>
>>> No one enjoys this. Well, statistically speaking, I'm sure there is a
>>> handful of people that do. Though as a general rule, this is tedious
>>> work
>>> that most Csounders would rather do without.
>>>
>>> I propose that we develop an instrument templating system for handling,
>>> importing and reusing instruments.
>>>
>>> In a nutshell, an instrument template is basically a Csound instrument,
>>> minus an assigned instrument number, plus it can support additional
>>> variables the can be designated when constructed. Here is an example of
>>> what a Csound instrument template might look like:
>>>
>>> template Sinewave440
>>> a1 oscils 1, 440, 1
>>> out a1
>>> end_template
>>>
>>> In this very basic example, the code in the body is 100% Csound. This is
>>> important because templates should look familiar to Csounders. Templates
>>> would exist in an orchestra, or in an external file. In order to use
>>> this
>>> template, an instrument must be created from it. The code to do this
>>> might look like this:
>>>
>>> create_instr 1 Sinewave440
>>>
>>> Or if the template exists in external file:
>>>
>>> import_template Sinewave440 from "./foo.orc"
>>> create_instr 1 Sinewave440
>>>
>>> The instrument as it is only works when nchnls is set to one. Since
>>> portability is a goal, I will modify this template to make it more of a
>>> general purpose template. Instead of sending a1 to the dac using out, I
>>> will instead send it to an audio buss using the upcoming outleta opcode.
>>>
>>> template Sinewave262 #output
>>> a1 oscils 1, 262, 1
>>> outleta a1, #output
>>> end_template
>>>
>>> Here, I introduced template arguments. The example uses one argument,
>>> #output. What ever text is supplied as the first parameter will replace
>>> #output in the body of the template, much like a macro.
>>>
>>> create_instr 1 Sinewave262 "audio_out"
>>>
>>> After the preprocessor, the following Csound code is produced:
>>>
>>> instr 1
>>> a1 oscils 1, 262, 1
>>> outleta a1, "audio_out"
>>> endin
>>>
>>> To hear the audio, we still need to create an instrument that receives
>>> the
>>> audio and sends it to the dac or audio file.
>>>
>>> template StereoOut #left_input #right_input
>>> a1 inleta #left_input
>>> a2 inleta #right_input
>>> output a1, a2
>>> end_template
>>>
>>> create_instr 1 Sinewave262 "audio_out"
>>> create_instr 2 StereoOut "audio_out" "audio_out"
>>>
>>> After the preprocessor, the previous code would produce the following
>>> orchestra code:
>>>
>>> instr 1
>>> a1 oscils 1, 262, 1
>>> outleta a1, "audio_out"
>>> endin
>>>
>>> instr 2
>>> a1 inleta "audio_out"
>>> a2 inleta "audio_out"
>>> output a1, a2
>>> endin
>>>
>>> The greater implication is that instruments/templates could be used in a
>>> much more modular fashion. Since numbers and buss names aren't assigned
>>> until an instr is created, Csounders would be able to patch together
>>> complex systems far easier and faster than is currently possible.
>>>
>>> Here is a longer example that makes use of this theoretical patching
>>> system:
>>>
>>> template MySynth #output #fn
>>> iamp = p4
>>> ifreq = p5
>>> ifn = #fn
>>>
>>> a1 oscil iamp, ifreq, ifn
>>> outlet a1, #output
>>> end_template
>>>
>>> template TheVerb #input #output #reverb_time
>>> itime = #reverb_time
>>>
>>> a1 inleta #input
>>> a1 reverb a1, itime
>>>
>>> outlet a1, #output
>>> end_template
>>>
>>> template StereoOut #left #right
>>> a1 inleta #left
>>> a2 inleta #right
>>> output a1, a2
>>> end_template
>>>
>>> gir ftgen 33, 0, 8192, 10, 1
>>> gir ftgen 34, 0, 8192, 7, -1, 8192, 1
>>>
>>> create_instr 1 MySynth "synth_out_1" 33
>>> create_instr 2 MySynth "synth_out_2" 34
>>> create_instr 3 TheVerb "synth_out_2" "verb_out" 2.23
>>> create_instr 4 StereoOut "synth_out_1" "verb_out"
>>>
>>> The score:
>>>
>>> i 1 0 4 0.5 440 ; sine, panned hard left
>>> i 2 0 4 0.5 880 ; saw, panned hard right, sent to reverb
>>> i 3 0 -1
>>> i 4 0 -1
>>>
>>> This is only the beginning of an idea, and much more thought is required.
>>>
>>> Though I do believe that a system like this or similar would make Csound
>>> much more pleasant to work with, by leaps and bounds. Imagine having a
>>> library with hundreds of user contributed templates / fully functional
>>> synths that anyone can plug into their orchestras and patch into other
>>> synths and DSPs, without the headaches of the current system. That's the
>>> world I want to live in.
>>>
>>> Best,
>>> Jake
>>>
>>>
>>
>>
>
> --
> Mark
> _________________________________________
> When you get lemons, you make lemonade.
> When you get hardware, you make software.
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email
sympa@... with body "unsubscribe
> csound"
>
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.
