[Csnd] Csound 7
Date | 2018-06-09 15:00 |
From | Peter Burgess |
Subject | [Csnd] Csound 7 |
Do I remember rightly talk of a Csound 7 in the works? Is that something coming soon?
Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here
|
Date | 2018-06-09 17:47 |
From | Mauro Giubileo |
Subject | Re: [Csnd] Csound 7 |
I think it's in the works, but I don't know when it is expected to come out. There is a wiki page here: https://github.com/csound/csound/wiki/Changes-for-Csound-7 Honestly, I would like very much that in the next big Csound release you could pass parameters by reference to the UDOs. If you use many UDOs that take and return a-type variables, passing parameters by reference could improve real-time performance by a good margin. For now, in these cases, I'm using (or maybe I'm abusing) macros with arguments, instead of UDOs, but of course this is not an ideal solution. Regards,
Mauro
Il 2018-06-09 16:00 Peter Burgess ha scritto:
|
Date | 2018-06-09 19:43 |
From | Peter Burgess |
Subject | Re: [Csnd] Csound 7 |
Ok cool, cheers. I'll have a read through that. I think I did once before, but not for a long time On Sat, 9 Jun 2018, 17:47 Mauro Giubileo, <mgiubileo@computeraltafed.it> wrote:
|
Date | 2018-06-09 20:58 |
From | Steven Yi |
Subject | Re: [Csnd] Csound 7 |
You may wish to look at the issues for CS7 here: No timeline at the moment, though we have talked about getting CS7 to be the focus of dev work for a while. On Sat, Jun 9, 2018 at 11:44 AM Peter Burgess <pete.soundtechnician@gmail.com> wrote:
|
Date | 2018-06-10 17:58 |
From | Mauro Giubileo |
Subject | Re: [Csnd] Csound 7 |
Hi, Steven, I see from that page that pass-by-reference is in the to-do list... That's good! :-) However, I don't understand very much the mixed syntax in your example:
What do you think about it? Another thing I don't understand is what happens in Csound 6 with output variables (like 'asig' in the above example). Are they copied too, or are passed by reference to the caller? In the case they are copied too, I suppose the above code should be modified like that:
Best regards, Il 2018-06-09 21:58 Steven Yi ha scritto:
|
Date | 2018-06-10 19:48 |
From | Steven Yi |
Subject | Re: [Csnd] Csound 7 |
The new UDO syntax is a part of CS7 and makes it possible to work with user-defined data types with names longer than one character. My preference is to keep the old syntax as frozen and to have it maintained for backwards compatibility, and add new features to the newer style. For your example it's fine if there's only one data type coming in, but what of something like: opcode myOpcode, *a*a*a, *a*a*a asig1, asig2, asig3 xin ;; have to have some weird rule now on what asig1 is going to be by ref or value? ;; or do we have to notate *asig1, *asig2, *asig3 ??? xout &asig1,&asig2, &asig3 ;; hm, do we need ref or address-of operator? might be simpler to use & rather than c-style * endop versus opcode myOpcode(signal1:a*, signal2:a*, signal3:a*):(a*, a*, a*) endop (my pref is TYPE* rather than *TYPE) I think it gets a little noisy with older UDO syntax because everything is jammed together, rather than comma separated. On Sun, Jun 10, 2018 at 9:58 AM Mauro Giubileo |
Date | 2018-06-10 23:11 |
From | Mauro Giubileo |
Subject | Re: [Csnd] Csound 7 |
Hi Steven,
In the above code is clear to me that the programmer just want to work directly on the same asig1, asig2, asig3 vectors of the caller instrument (which, of course, could have different names in the caller) without have to copy them in new variables. I think the Csound parser should hide all the "inner works on the pointers" that you would see in a C/C++ code, that is, you should not have to use some C-like syntax like "&variable=..." or "*variable=..." inside the UDO. Best Regads, Il 2018-06-10 20:48 Steven Yi ha scritto:
|
Date | 2018-06-11 18:56 |
From | Mauro Giubileo |
Subject | Re: [Csnd] Csound 7 |
I would like to add an observation in your example: opcode myOpcode, *a*a*a, *a*a*a In the above example, being that in the intypes and outtypes strings you have already specified the variable types (*a), there is no more need to add '*' or '&' before the variable names for the input/output parameters of the xin/xout instructions. This info is already obtainable from the intypes/outtypes, so why you should re-specify it before the variable names? I think it would be redundant... Best Regards, Il 2018-06-11 00:11 Mauro Giubileo ha scritto:
|