| Chnget and invalue at i time as well as krate would be great.
Best,
Mike
On Oct 28, 2014 11:02 AM, "Steven Yi" < stevenyi@gmail.com> wrote: Oh I think it'd be a very bad idea to try to introduce some kind of separate k-rate var; the existing stuff is confusing enough! IMO, the problems of reading k-rate at i-time is not an issue with the var type, but rather what opcodes you use. If there's an issue with chnget, we can modify it to read at init-time too.
On Fri Oct 17 2014 at 4:22:25 PM Oeyvind Brandtsegg < oyvind.brandtsegg@ntnu.no> wrote: Just guessing, but it seems to me that enforcing a no-init of all
k-variables might break something, while enforcing init of k-variables
should not break anything... (?)
2014-10-17 21:51 GMT+02:00 Rory Walsh <rorywalsh@ear.ie>:
> Would forcing all k-rate variables to init at init time break existing
> instruments? If not, could it be done? I have a dream that one day i
> and k rate variables shall be judged equally during an init pass. And
> that man shall no more scratch his head wondering why k keeps falling
> through conditional statements!
>
> On 17 October 2014 20:41, Andres Cabrera <mantaraya36@gmail.com> wrote:
>> Not sure what the best way to handle it would be. Maybe all k-rate variables
>> should be forced to initialize at init, but that doesn't seem like a great
>> idea. Maybe none should. Or maybe there should be a way of marking opcodes
>> to let people know that the opcode intializes or doesn't initialize k-rate
>> variables. This could be something enforced by csound, or it could be a
>> documentation thing only.
>>
>> I'm just throwing it out there to see what people think :)...
>>
>> Cheers,
>> Andrés
>>
>> On Fri, Oct 17, 2014 at 11:36 AM, Rory Walsh <rorywalsh@ear.ie> wrote:
>>>
>>> This would be an internal only thing? k-rate variable not being
>>> initialized at i-rate has always made me irate.
>>>
>>> On 17 October 2014 20:32, Andres Cabrera <mantaraya36@gmail.com> wrote:
>>> > Hi,
>>> >
>>> > The discussion on k-rate arrays at init time made me wonder if it might
>>> > be
>>> > beneficial to have two separate types of k-rate. One that can be
>>> > processed
>>> > at init time, and one that can't. This might be complicated to
>>> > implement,
>>> > but it would solve one of the big confusions in the language, where
>>> > things
>>> > don't work because a particular opcode doesn't write at init time to
>>> > k-rate
>>> > variable, while an opcode following it reads it at init time. It would
>>> > also
>>> > clarify the incosistencies that can occur between the invalue and chnget
>>> > opcodes. invalue reads the value during the init pass, while chnget
>>> > doesn't.
>>> >
>>> > Maybe it should be enforced that no k-rate variables should be written
>>> > to,
>>> > no matter how convenient that seems?
>>> >
>>> > Cheers,
>>> > Andrés
>>> >
>>> >
>>> > ------------------------------------------------------------------------------
>>> > Comprehensive Server Monitoring with Site24x7.
>>> > Monitor 10 servers for $9/Month.
>>> > Get alerted through email, SMS, voice calls or mobile push
>>> > notifications.
>>> > Take corrective actions from your mobile device.
>>> > http://p.sf.net/sfu/Zoho
>>> > _______________________________________________
>>> > Csound-devel mailing list
>>> > Csound-devel@lists.sourceforge.net
>>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> >
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Comprehensive Server Monitoring with Site24x7.
>>> Monitor 10 servers for $9/Month.
>>> Get alerted through email, SMS, voice calls or mobile push notifications.
>>> Take corrective actions from your mobile device.
>>> http://p.sf.net/sfu/Zoho
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Comprehensive Server Monitoring with Site24x7.
>> Monitor 10 servers for $9/Month.
>> Get alerted through email, SMS, voice calls or mobile push notifications.
>> Take corrective actions from your mobile device.
>> http://p.sf.net/sfu/Zoho
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
--
Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205
http://flyndresang.no/
http://www.partikkelaudio.com/
http://soundcloud.com/brandtsegg
http://soundcloud.com/t-emp
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel
------------------------------------------------------------------------------
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel
|