| This brings up an interesting situation. In this case, I would argue
we might want to change the array version of bformenc1 to require an
i-rate format argument (maybe call it "iorder" and say it allows 1,2,
or 3 for first, second, third order amibsonics). That would seem to
me to make the case clearer, and remove the dependency on the outarg.
This would also make it possible to use the bformenc1 opcode as a
function without ambiguity.
I still believe that using "aarray[]" is still the right thing. When
we look at other manual entries, we see things like:
ares vco2 kamp, kcps [, imode] [, kpw] [, kphs] [, inyx]
We can say of the "ares" output that vco2 outputs an a-rate variable.
That we have called it ares in the manual is only a hint to the user,
as they can call it whatever they want. The important thing really to
be concerned with is the type of the variable being output.
In most languages I'm familiar with, the output variable's name isn't
even given. For example:
int doSomething(int arg1, int val); // C, Java
(int)doFunction:(int)arg1 val:(int)val; // Obj-C
intersperse :: a -> [[a]] -> [a] // Haskell, says a list of a is what
is returned
I think the focus in the documentation should be more on the type,
rather than names of variables. If we used just "aarray", then it
doesn't show that it's an array type. I'd argue it'd be even more
confusing then, as a user might see it and think "oh, bformenc1
outputs an a-var, that'd odd...". To me, using "aarray[]" simply says
more in less words.
I agree though that the description text should explicitly explain
what is going on, but I do think that the information is clearer with
aarray[] to start.
To note, the confusion about this may stem from there not being a
well-defined specification on array usage, both for users and
developers. Really, anytime an opcode outputs an array, it should be
assumed that it is a completely new entity, and the opcode should have
full license to re-size and re-dimension the array. That's so that the
data can be worked with in an immutable way.
On Sun, Sep 22, 2013 at 4:17 PM, joachim heintz wrote:
> hi steven, john -
>
> thanks for your replies (john on the user list). i understand what you
> mean, but my concern is this:
>
> 1) a user who looks at the manual reference and sees this:
> >> aarray[] bformenc1 asig, kalpha, kbeta
>
> 2) this user will think: "okay, i have to write something like
> 'aarray[]' as output."
>
> 3) but this is wrong, as we have discussed here earlier
> (http://csound.1045644.n5.nabble.com/arrays-wish-list-tt5723850.html#none --
> in particular steven's mail May 27, 2013; 1:23am):
> - 'aarray[]' is only correct when an array is created.
> - whenever this variable is used later to designate the array as a
> whole, it must be written without brackets.
> if this is not consistent, it is very confusing.
>
> 4) in the case of bformenc1, an array *must* be created earlier (before
> being used in bformenc1), because there are three possibilities:
> bformenc1 can produce a b-format in first order (4 channels), or second
> order (9 channels), or third order (16 channels).
>
> 5) so the user will - because of 2) - write something like:
> anoise pinkish 1
> kalpha line 0, p3, 720
> aBform[] init 9 ;second order
> aBform[] bformenc1 anoise, kalpha, 0
>
> which is inconsistent with the usage described in 3). instead it should be:
> anoise pinkish 1
> kalpha line 0, p3, 720
> aBform[] init 9
> aBform bformenc1 anoise, kalpha, 0
>
>
> so i'd vote
> a) to write in the bformenc1 entry without brackets:
> aarray bformenc1 asig, kalpha, kbeta
> for not confusing the usage of brackets, but
> b) to explain in the description of "aarray" that this is an array and
> not a single audio signal.
> i think we should mention in this context that you must have initialized
> aarray before with a certain size. maybe we could point to the manual
> description about how to use arrays in general.
>
> best -
>
> joachim
>
>
>
> Am 20.09.2013 19:33, schrieb Steven Yi:
>> I think using the a[] notation is correct. The document is saying not
>> only describing the use of the variable, but also the type. In this
>> case, it needs to show that it is going to output a type of a[].
>>
>> In something like C, you might see a function declaration like:
>>
>> char[] someFunction(int, float);
>>
>> even if in usage it is used as:
>>
>> char[] val;
>>
>> val = someFunction(3, 4.3);
>>
>> or:
>>
>> char[] val = someFunction(3, 4.3);
>>
>> (I may have mixed up if the brackets go with val[] or not, but the
>> point is still the same).
>>
>> In the case of bformenc1, I don't think it shoud be assumed that the
>> array output would be pre-declared. Really, whatever bformenc1
>> outputs will overwrite whatever is in the aarray[] variable.
>>
>> steven
>>
>> On Fri, Sep 20, 2013 at 7:05 AM, joachim heintz wrote:
>>> hi -
>>>
>>> subsequent to john's audio-array implementation of some opcodes i had
>>> put a question on the user list. perhaps it has been overseen, and this
>>> might be the better place. so this is the question again:
>>>
>>> at the bformenc1 page is written:
>>> aarray[] bformenc1 asig, kalpha, kbeta
>>>
>>> should it not be instead:
>>> aarray bformenc1 asig, kalpha, kbeta
>>>
>>> so, *without* the square brackets? i assume that the array has to be
>>> initialized with a certain size before?
>>>
>>> we should be very careful where to use brackets or not -- i am afraid we
>>> will create a lot of confusion if this is not consistent. i am willing
>>> to get into the manual pages and correct, but at first i want to be sure
>>> that it is really a mistake.
>>>
>>> best -
>>>
>>> joachim
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
>>> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
>>> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
>>> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
>> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
>> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
>> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
>> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
> ------------------------------------------------------------------------------
> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13.
> http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net |