[Csnd] filevalid at krate?
| Date | 2018-05-26 13:18 |
| From | Kevin Welsh |
| Subject | [Csnd] filevalid at krate? |
Speaking of filevalid... it seems filevalid only operates at irate, but strings can operate at krate.
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
Would it be possible for filevalid to get "native" k-rate output? I've written a UDO wrapper to force reinits when the input string changes, and that seems to work fine for my purposes... but it does seem like a logical addition to eventually add to the builtin opcode. Here's the example UDO for anyone interested: opcode FileValidK,k,S SFileName xin if(changed(SFileName)==1) then reinit MyReinit endif MyReinit: if(strlenk(SFileName)>0) then iFileExists filevalid SFileName endif kIsValid = iFileExists xout kIsValid endop |
| Date | 2018-05-26 13:35 |
| From | jpff |
| Subject | Re: [Csnd] filevalid at krate? |
Would a version that accepted k-rate input anfd gave k-rate outut be
sufficient? I think that would just require a nw entry in the opcode list
with no new code.
On Sat, 26 May 2018, Kevin Welsh wrote:
> Speaking of filevalid... it seems filevalid only operates at irate, but
> strings can operate at krate.
> Would it be possible for filevalid to get "native" k-rate output? I've
> written a UDO wrapper to force reinits when the input string changes, and that
> seems to work fine for my purposes... but it does seem like a logical addition
> to eventually add to the builtin opcode.
>
> Here's the example UDO for anyone interested:
>
> opcode FileValidK,k,S
> SFileName xin
>
> if(changed(SFileName)==1) then
> reinit MyReinit
> endif
>
> MyReinit:
> if(strlenk(SFileName)>0) then
> iFileExists filevalid SFileName
> endif
> kIsValid = iFileExists
>
> xout kIsValid
> endop
> 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
>
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-05-26 13:47 |
| From | Kevin Welsh |
| Subject | Re: [Csnd] filevalid at krate? |
I think what you're proposing is that there be two different versions of the opcode, one that takes in an irate string and outputs an irate var, and a different opcode that takes in a krate string, and output a krate var. Would this be two differently named opcodes as compared to one opcode that could do either based on the output request of the user? I'm not particularly picky in how it's implemented, so that should suit my needs just fine. But I'm also not very knowledgable about what goes on "behind the curtain" with csound, so whatever is determined to be the best balance between easy to implement, logical for users, backwards compatible, and forward thinking. :) On Sat, May 26, 2018 at 8:35 AM, jpff <jpff@codemist.co.uk> wrote: Would a version that accepted k-rate input anfd gave k-rate outut be sufficient? I think that would just require a nw entry in the opcode list with no new code. |
| Date | 2018-05-26 14:04 |
| From | John ff |
| Subject | Re: [Csnd] filevalid at krate? |
Same name decided by result type
Sent from Blue
On 26 May 2018, at 13:48, Kevin Welsh <tgrey1@gmail.com> wrote:
|
| Date | 2018-05-26 14:09 |
| From | Kevin Welsh |
| Subject | Re: [Csnd] filevalid at krate? |
Perfect, I think that sounds like the best case scenario, but I wasn't sure if there might be a reason it was impossible. I know k-rate strings are a little bit outside of the ordinary, so I wasn't sure what complications might arise. On Sat, May 26, 2018 at 9:04 AM, John ff <jpff@codemist.co.uk> wrote:
|
| Date | 2018-05-26 14:11 |
| From | Kevin Welsh |
| Subject | Re: [Csnd] filevalid at krate? |
Sorry, this dawned on me as soon as I hit send... There might also be a use case where a user provides an i-rate string and requests a k-rate result. I'm not sure if the i vs k rate string input is handled differently, so perhaps it's worth mentioning. On Sat, May 26, 2018 at 9:09 AM, Kevin Welsh <tgrey1@gmail.com> wrote:
|