woops sorry about that

On Jun 16, 2006, at 10:03 AM, Istvan Varga wrote:

> The index and output must be of the same type.
>
> On Friday 16 June 2006 20:01, matt ingalls wrote:
>
>> this line:
>>
>> 	aout table kndx, 1, 0, 0, 1
>>
>> throws this error:
>>
>> 	error:  input arg 'kndx' of type k not allowed when expecting a,
>
>
> _______________________________________________
> 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

It didn't used to be?  And this feature has busted many orchestras  
and UDO's

Dr. B.

On Jun 16, 2006, at 1:03 PM, Istvan Varga wrote:

> The index and output must be of the same type.
>
> On Friday 16 June 2006 20:01, matt ingalls wrote:
>
>> this line:
>>
>> 	aout table kndx, 1, 0, 0, 1
>>
>> throws this error:
>>
>> 	error:  input arg 'kndx' of type k not allowed when expecting a,
>
>
> _______________________________________________
> 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

I am sorry, but this *change* has broken many of the UDO's.  They  
would need to be rewritten.

I hope that everyone is aware of this and can deal with the new  
problem of backward incompatibility
that you have introduced into 5.0.

-dB

On Jun 16, 2006, at 6:16 PM, Istvan Varga wrote:

> On Saturday 17 June 2006 01:02, Dr. Richard Boulanger wrote:
>
>> It didn't used to be?  And this feature has busted many orchestras
>> and UDO's
>
> It is true that 4.23 and older versions did not reject inconsistent
> output/index types, but it has been more of an artifact than an actual
> feature. For example, with a-rate output and k-rate index, it resulted
> in garbage being read from memory and used as the table index. In any
> case, even when such type combinations make sense (usually with
> ksmps=1), they can be avoided easily.
>
>
> _______________________________________________
> 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

Dr. Richard Boulanger wrote:

> I am sorry, but this *change* has broken many of the UDO's.  They  
> would need to be rewritten.

Don't you mean "fixed" instead of "rewritten"?

> I hope that everyone is aware of this and can deal with the new  
> problem of backward incompatibility
> that you have introduced into 5.0.

In any piece of software as complicated as Csound, there are times
where backwards compatibility *has* to be broken in order to move
forward.

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo
+-----------------------------------------------------------+
"C++ is history repeated as tragedy. Java is history repeated as farce."
-- Scott McKay


_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

In any case, I don't believe the old manuals say anything about the
behaviour of 'table' with control-rate input and audio-rate output.  It
could be useful to add that capability.  The problem that would have to
be addressed is that there are at least three methods that might occur
or that might have occurred to people as "making sense" in this
situation. Either:

1 - the table is read at k-rate and the value is simply copied ksmps
times to the audio-rate output variable [or]
2 - the table read position is linearly-interpolated from k-rate to
a-rate so that the table is effectively read at a-rate [or]
3 - the table is read at k-rate but the output value is interpolated
somehow or other to an a-rate variable

I would vote for option 1, myself.  The problem with option 3 is that
there are numerous sensible ways of interpolating audio values; option 2
while unambiguous seems somewhat baroque in the days of cheap memory and
fast processors [why not index the table with an audio rate variable?].

Option 1 would then effectively be a shorthand for the following:
kvalue table kindex, iMyTable
avalue upsamp kvalue

Option 2 could always be reconstructed with one extra line of code:
aindex interp kindex
avalue table aindex, iMyTable

As could the linear interpretation of option 3:
kvalue table kindex, iMyTable
avalue interp kvalue

Yours truly,
David

Erik de Castro Lopo wrote:
> Dr. Richard Boulanger wrote:
> 
>> I am sorry, but this *change* has broken many of the UDO's.  They  
>> would need to be rewritten.
> 
> Don't you mean "fixed" instead of "rewritten"?
> 
>> I hope that everyone is aware of this and can deal with the new  
>> problem of backward incompatibility
>> that you have introduced into 5.0.
> 
> In any piece of software as complicated as Csound, there are times
> where backwards compatibility *has* to be broken in order to move
> forward.
> 
> Erik


_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

>>>>> "David" == David Ogborn  writes:

 David> In any case, I don't believe the old manuals say anything about the
 David> behaviour of 'table' with control-rate input and audio-rate output.  It
 David> could be useful to add that capability.  The problem that would have to
 David> be addressed is that there are at least three methods that might occur
 David> or that might have occurred to people as "making sense" in this
 David> situation. Either:

 David> 1 - the table is read at k-rate and the value is simply copied ksmps
 David> times to the audio-rate output variable [or]
 David> 2 - the table read position is linearly-interpolated from k-rate to
 David> a-rate so that the table is effectively read at a-rate [or]
 David> 3 - the table is read at k-rate but the output value is interpolated
 David> somehow or other to an a-rate variable

I assumed option 1 was obvious, and assumed that that was what it did.
==John ff


_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I would prefer that there was some way not to break existing orchestras
while at the same time improving the system.  It sounds to me like you
have come up with some.

If you were to check out any of the Table Writing UDOs developed by
Victor, you would see that they no longer work with Csound5

and these are pretty wonderful, they are examples and models for my
students on how to do Max/MSP like things - that are so commonly
and simply done in that environment - in Csound.


Dr. B.
On Jun 17, 2006, at 4:13 AM, Istvan Varga wrote:

> It is also an option to allow inconsistent types with ksmps=1 (the  
> only
> case when the Csound 4 code actually made sense), maybe with a warning
> message, and print the error if ksmps is not 1.
>
>
> _______________________________________________
> 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

Dr. Richard Boulanger wrote:

> I would prefer that there was some way not to break existing orchestras
> while at the same time improving the system.

A better solution would be to detect these things and give a good
error message like:

   Error on line X : a rate veriable used where a k rate variable was
   expected.

This would make the existing orchestras easy to fix and avoid having
to add layers and layers of work arounds to the code.

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo
+-----------------------------------------------------------+
"To me C++ seems to be a language that has sacrificed orthogonality
and elegance for random expediency." -- Meilir Page-Jones


_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

But this isn't a work around in the code.  You see, the code worked a  
certain way, and
some fantastic orchestras and UDOs were designed based on how the  
code worked
(for years) - as we make improvements, we do need to maintain  
backward compatibility
- the prime directive actually!

Rather than *improve* opcodes and change their behavior, we need to  
create new ones
and/or make new behaviours options or make exceptions for old/new  
behaviors so that they
both work regardless.

-Dr. B.


On Jun 17, 2006, at 9:01 AM, Erik de Castro Lopo wrote:

> Dr. Richard Boulanger wrote:
>
>> I would prefer that there was some way not to break existing  
>> orchestras
>> while at the same time improving the system.
>
> A better solution would be to detect these things and give a good
> error message like:
>
>    Error on line X : a rate veriable used where a k rate variable was
>    expected.
>
> This would make the existing orchestras easy to fix and avoid having
> to add layers and layers of work arounds to the code.
>
> Erik
> -- 
> +-----------------------------------------------------------+
>   Erik de Castro Lopo
> +-----------------------------------------------------------+
> "To me C++ seems to be a language that has sacrificed orthogonality
> and elegance for random expediency." -- Meilir Page-Jones
>
>
> _______________________________________________
> 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

Csound5 is breaking Csound4 things.  THIS IS NOT RIGHT.

-dB

On Jun 17, 2006, at 9:01 AM, Erik de Castro Lopo wrote:

> Dr. Richard Boulanger wrote:
>
>> I would prefer that there was some way not to break existing  
>> orchestras
>> while at the same time improving the system.
>
> A better solution would be to detect these things and give a good
> error message like:
>
>    Error on line X : a rate veriable used where a k rate variable was
>    expected.
>
> This would make the existing orchestras easy to fix and avoid having
> to add layers and layers of work arounds to the code.
>
> Erik
> -- 
> +-----------------------------------------------------------+
>   Erik de Castro Lopo
> +-----------------------------------------------------------+
> "To me C++ seems to be a language that has sacrificed orthogonality
> and elegance for random expediency." -- Meilir Page-Jones
>
>
> _______________________________________________
> 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