As time goes on, I find myself using more and more UDOs, as they rock
and they save me a lot of time. However, I ran into a small snag. It
seems that while I can create events that start up instruments within
instr 0, I can't do the same with UDOs.  For example, this is possible
inside instr 0:


event_i "i", 1, 0, 1

instr 1
    ...
endin


However, this is not possible:


gifoo MyOpcode 1, 2

opcode MyOpcode i, ii
    ...
endop



I can certainly write a wrapper instrument. Which is exactly what I
plan to do.  However, doing so makes writing the UDO in the first
place slightly redundant. Not sure if this is technically feasible, or
even if this is a worthwhile upgrade. It might just require a new
opcode that works like subinstr, like this:

gifoo udo "MyOpcode", 1, 2


Just food for thought.

Best,
Jake

Hi,

You need to bear in mind that instr 0 can only hold init time
statements, so making an Udo presents no real advantage to doing a
macro or writing the text directly.

Or what am I missing?

Cheers,
Andrés

On Fri, Dec 4, 2009 at 11:00 PM, Jacob Joaquin  wrote:
> As time goes on, I find myself using more and more UDOs, as they rock
> and they save me a lot of time. However, I ran into a small snag. It
> seems that while I can create events that start up instruments within
> instr 0, I can't do the same with UDOs.  For example, this is possible
> inside instr 0:
>
>
> event_i "i", 1, 0, 1
>
> instr 1
>    ...
> endin
>
>
> However, this is not possible:
>
>
> gifoo MyOpcode 1, 2
>
> opcode MyOpcode i, ii
>    ...
> endop
>
>
>
> I can certainly write a wrapper instrument. Which is exactly what I
> plan to do.  However, doing so makes writing the UDO in the first
> place slightly redundant. Not sure if this is technically feasible, or
> even if this is a worthwhile upgrade. It might just require a new
> opcode that works like subinstr, like this:
>
> gifoo udo "MyOpcode", 1, 2
>
>
> Just food for thought.
>
> Best,
> Jake
> --
> The Csound Blog - http://csound.noisepages.com/
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>



-- 


Andrés


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

I figured that only i-rate opcodes, or the init stage of opcodes would
work with instr 0. Part of reasoning has to do with personally wanting
things to be somewhat consistent in Csound. I-rate built-in opcodes,
and I'm guessing plugin opcodes, can be used in instr 0. Though
user-defined opcodes cannot.

Writing the text directly is fine in cases where one only needs an
operation done once, and the code to do so small. As more operations
are needed, and the code to accomplish a specific task grows,
consolidating the code into a single instrument and/or opcode makes a
lot of sense, as it saves keystrokes, increases usability, helps
reduce bugs, etc.

Philosophically speaking, I have a problem with functional macros.
Plus, I'm not sure these would work in all situations that opcodes, if
they worked, would. I have some opcodes now that are pretty complex,
and I can't imagine trying to implement these as macros.

I've also discovered a weird behavior with using wrapper instrs to
opcodes.  For example, I've attached instr_as_wrapper_break.csd that
shows why wrappers may not work as expected.

In a nutshell, I have an opcode that is used to created a sine table.
Instr 1 is a wrapper that calls the opcode. I use event_i at beat 0 to
call instr 1 to create the sine table. In the score, I call instr 2,
also at beat 0, that tries to use the sine table, but can't because it
hasn't be created yet. I could just call instr 1 from the score.

Best,
Jake
-- 
The Csound Blog - http://csound.noisepages.com/




On Mon, Dec 7, 2009 at 10:02 AM, Andres Cabrera  wrote:
> Hi,
>
> You need to bear in mind that instr 0 can only hold init time
> statements, so making an Udo presents no real advantage to doing a
> macro or writing the text directly.
>
> Or what am I missing?
>
> Cheers,
> Andrés
>
> On Fri, Dec 4, 2009 at 11:00 PM, Jacob Joaquin  wrote:
>> As time goes on, I find myself using more and more UDOs, as they rock
>> and they save me a lot of time. However, I ran into a small snag. It
>> seems that while I can create events that start up instruments within
>> instr 0, I can't do the same with UDOs.  For example, this is possible
>> inside instr 0:
>>
>>
>> event_i "i", 1, 0, 1
>>
>> instr 1
>>    ...
>> endin
>>
>>
>> However, this is not possible:
>>
>>
>> gifoo MyOpcode 1, 2
>>
>> opcode MyOpcode i, ii
>>    ...
>> endop
>>
>>
>>
>> I can certainly write a wrapper instrument. Which is exactly what I
>> plan to do.  However, doing so makes writing the UDO in the first
>> place slightly redundant. Not sure if this is technically feasible, or
>> even if this is a worthwhile upgrade. It might just require a new
>> opcode that works like subinstr, like this:
>>
>> gifoo udo "MyOpcode", 1, 2
>>
>>
>> Just food for thought.
>>
>> Best,
>> Jake
>> --
>> The Csound Blog - http://csound.noisepages.com/
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>
>
>
> --
>
>
> Andrés
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Hi,

I think that since the score is fixed, the items in the score are
processed and queued before any "real-time" events, even if they are
i-time like event_i, so I am not surprised by this behavior. But I see
your point that it would be nice if there was some elegant way to
avoid it.

Cheers,
Andrés

On Tue, Dec 8, 2009 at 4:59 PM, Jacob Joaquin  wrote:
> I figured that only i-rate opcodes, or the init stage of opcodes would
> work with instr 0. Part of reasoning has to do with personally wanting
> things to be somewhat consistent in Csound. I-rate built-in opcodes,
> and I'm guessing plugin opcodes, can be used in instr 0. Though
> user-defined opcodes cannot.
>
> Writing the text directly is fine in cases where one only needs an
> operation done once, and the code to do so small. As more operations
> are needed, and the code to accomplish a specific task grows,
> consolidating the code into a single instrument and/or opcode makes a
> lot of sense, as it saves keystrokes, increases usability, helps
> reduce bugs, etc.
>
> Philosophically speaking, I have a problem with functional macros.
> Plus, I'm not sure these would work in all situations that opcodes, if
> they worked, would. I have some opcodes now that are pretty complex,
> and I can't imagine trying to implement these as macros.
>
> I've also discovered a weird behavior with using wrapper instrs to
> opcodes.  For example, I've attached instr_as_wrapper_break.csd that
> shows why wrappers may not work as expected.
>
> In a nutshell, I have an opcode that is used to created a sine table.
> Instr 1 is a wrapper that calls the opcode. I use event_i at beat 0 to
> call instr 1 to create the sine table. In the score, I call instr 2,
> also at beat 0, that tries to use the sine table, but can't because it
> hasn't be created yet. I could just call instr 1 from the score.
>
> Best,
> Jake
> --
> The Csound Blog - http://csound.noisepages.com/
>
>
>
>
> On Mon, Dec 7, 2009 at 10:02 AM, Andres Cabrera  wrote:
>> Hi,
>>
>> You need to bear in mind that instr 0 can only hold init time
>> statements, so making an Udo presents no real advantage to doing a
>> macro or writing the text directly.
>>
>> Or what am I missing?
>>
>> Cheers,
>> Andrés
>>
>> On Fri, Dec 4, 2009 at 11:00 PM, Jacob Joaquin  wrote:
>>> As time goes on, I find myself using more and more UDOs, as they rock
>>> and they save me a lot of time. However, I ran into a small snag. It
>>> seems that while I can create events that start up instruments within
>>> instr 0, I can't do the same with UDOs.  For example, this is possible
>>> inside instr 0:
>>>
>>>
>>> event_i "i", 1, 0, 1
>>>
>>> instr 1
>>>    ...
>>> endin
>>>
>>>
>>> However, this is not possible:
>>>
>>>
>>> gifoo MyOpcode 1, 2
>>>
>>> opcode MyOpcode i, ii
>>>    ...
>>> endop
>>>
>>>
>>>
>>> I can certainly write a wrapper instrument. Which is exactly what I
>>> plan to do.  However, doing so makes writing the UDO in the first
>>> place slightly redundant. Not sure if this is technically feasible, or
>>> even if this is a worthwhile upgrade. It might just require a new
>>> opcode that works like subinstr, like this:
>>>
>>> gifoo udo "MyOpcode", 1, 2
>>>
>>>
>>> Just food for thought.
>>>
>>> Best,
>>> Jake
>>> --
>>> The Csound Blog - http://csound.noisepages.com/
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>
>>
>>
>>
>> --
>>
>>
>> Andrés
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"



-- 


Andrés


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

I'm going to have to run more tests to see which opcodes work before
or after score events. It seemed to me that instr 0 would be the
perfect place to initialize conditions of the orchestra.

Best,
Jake
-- 
The Csound Blog - http://csound.noisepages.com/


On Tue, Dec 8, 2009 at 10:51 AM, Andres Cabrera  wrote:
> Hi,
>
> I think that since the score is fixed, the items in the score are
> processed and queued before any "real-time" events, even if they are
> i-time like event_i, so I am not surprised by this behavior. But I see
> your point that it would be nice if there was some elegant way to
> avoid it.
>
> Cheers,
> Andrés


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Hi,

I would think all score events in the score are processed previous to
score events in the orchestra.

Cheers,
Andrés

On Tue, Dec 8, 2009 at 7:11 PM, Jacob Joaquin  wrote:
> I'm going to have to run more tests to see which opcodes work before
> or after score events. It seemed to me that instr 0 would be the
> perfect place to initialize conditions of the orchestra.
>
> Best,
> Jake
> --
> The Csound Blog - http://csound.noisepages.com/
>
>
> On Tue, Dec 8, 2009 at 10:51 AM, Andres Cabrera  wrote:
>> Hi,
>>
>> I think that since the score is fixed, the items in the score are
>> processed and queued before any "real-time" events, even if they are
>> i-time like event_i, so I am not surprised by this behavior. But I see
>> your point that it would be nice if there was some elegant way to
>> avoid it.
>>
>> Cheers,
>> Andrés
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"



-- 


Andrés


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Comparing this i statements to f statements at beat 0.

itemp ftgen 1, 0, 8192, 10, 1

creates a table before

f 1 0 8192 10 1 1 1 1 1

Thus, the order is instr 0, then the score. This is opposite to how i
events work, where the score happens first, and the orchestra later.

Best,
Jake
-- 
The Csound Blog - http://csound.noisepages.com/

On Tue, Dec 8, 2009 at 11:24 AM, Andres Cabrera  wrote:
> Hi,
>
> I would think all score events in the score are processed previous to
> score events in the orchestra.
>
> Cheers,
> Andrés
>
> On Tue, Dec 8, 2009 at 7:11 PM, Jacob Joaquin  wrote:
>> I'm going to have to run more tests to see which opcodes work before
>> or after score events. It seemed to me that instr 0 would be the
>> perfect place to initialize conditions of the orchestra.
>>
>> Best,
>> Jake
>> --
>> The Csound Blog - http://csound.noisepages.com/
>>
>>
>> On Tue, Dec 8, 2009 at 10:51 AM, Andres Cabrera  wrote:
>>> Hi,
>>>
>>> I think that since the score is fixed, the items in the score are
>>> processed and queued before any "real-time" events, even if they are
>>> i-time like event_i, so I am not surprised by this behavior. But I see
>>> your point that it would be nice if there was some elegant way to
>>> avoid it.
>>>
>>> Cheers,
>>> Andrés
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>
>
> --
>
>
> Andrés
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Oh.

Thanks for exploring. Interesting.

It might be good to make this quirk consistent...

Cheers,
Andrés

On Tue, Dec 8, 2009 at 7:33 PM, Jacob Joaquin  wrote:
> Comparing this i statements to f statements at beat 0.
>
> itemp ftgen 1, 0, 8192, 10, 1
>
> creates a table before
>
> f 1 0 8192 10 1 1 1 1 1
>
> Thus, the order is instr 0, then the score. This is opposite to how i
> events work, where the score happens first, and the orchestra later.
>
> Best,
> Jake
> --
> The Csound Blog - http://csound.noisepages.com/
>
> On Tue, Dec 8, 2009 at 11:24 AM, Andres Cabrera  wrote:
>> Hi,
>>
>> I would think all score events in the score are processed previous to
>> score events in the orchestra.
>>
>> Cheers,
>> Andrés
>>
>> On Tue, Dec 8, 2009 at 7:11 PM, Jacob Joaquin  wrote:
>>> I'm going to have to run more tests to see which opcodes work before
>>> or after score events. It seemed to me that instr 0 would be the
>>> perfect place to initialize conditions of the orchestra.
>>>
>>> Best,
>>> Jake
>>> --
>>> The Csound Blog - http://csound.noisepages.com/
>>>
>>>
>>> On Tue, Dec 8, 2009 at 10:51 AM, Andres Cabrera  wrote:
>>>> Hi,
>>>>
>>>> I think that since the score is fixed, the items in the score are
>>>> processed and queued before any "real-time" events, even if they are
>>>> i-time like event_i, so I am not surprised by this behavior. But I see
>>>> your point that it would be nice if there was some elegant way to
>>>> avoid it.
>>>>
>>>> Cheers,
>>>> Andrés
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>
>>
>> --
>>
>>
>> Andrés
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"



-- 


Andrés


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

The question now is, was this an intentional design decision? Or a bug?

Best,
Jake
-- 
The Csound Blog - http://csound.noisepages.com/


On Tue, Dec 8, 2009 at 11:35 AM, Andres Cabrera  wrote:
> Oh.
>
> Thanks for exploring. Interesting.
>
> It might be good to make this quirk consistent...
>
> Cheers,
> Andrés
>
> On Tue, Dec 8, 2009 at 7:33 PM, Jacob Joaquin  wrote:
>> Comparing this i statements to f statements at beat 0.
>>
>> itemp ftgen 1, 0, 8192, 10, 1
>>
>> creates a table before
>>
>> f 1 0 8192 10 1 1 1 1 1
>>
>> Thus, the order is instr 0, then the score. This is opposite to how i
>> events work, where the score happens first, and the orchestra later.


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"