Resource light looping? Tell us more. I'm sure we can hep you out.

On 12 September 2014 22:17, Daisy Audio  wrote:
> Evening all,
>
> A little while ago someone contacted me off list and said they had some nice
> resource light looping instrument code they'd send me. They never did and I
> can't recall who it was or find anything in my email.
>
> If this rings a bell with anyone, or anyone has anything along those lines,
> I'd love the files or text.
>
> Please either contact me directly or via the list as I'm sure others would
> find it useful.
>
> Thanks and have a good weekend.
>
> Dominic
>

How are you doing it at the moment? I usually just read from function
tables that load the loops on startup. I tried using some of the file
reading opcodes but they weren't fast enough. My largest sampler takes
a few moments to get everything in order on startup. But once
everything is loaded to RAM it's pretty quick. On the RPi you may need
to reduce the sampling rate. You will probably also have to experiment
with different ksmps values until you find the optimum one for the
system.

On 13 September 2014 17:06, Daisy Audio  wrote:
> Actually realised I didn't send the message I meant to the list originally.
> Doh!
>
> So, I'm basically looking for the least CPU intensive way of looping either
> prerecorded audio or live recorded audio or both ideally. Either would work.
> I know all the usual ways of achieving this, just wondered if anyone had
> found a lightweight, system resource friendly way of doing it.
>
> Ideally the less CPU I can use the better. Ram isn't an issue, so anything
> that simply calls the audio files into ram is fine, and usually far more
> responsive in live use.
>
> The overall file I use live is already battering my system so anything I can
> do to lighten the load would be extremely helpful!
>
> Currently running the live setup on OS X, but will be moving it over to Arch
> a Linux very soon, but don't think that'll change anything I can or can't
> use, hopefully!
>
> The eventual plan is to move the looping system onto a dedicated RPi that'll
> run nothing but Arch and the Csound looper.
>
> Thanks
>
> Dominic
>
>
> On Saturday, September 13, 2014, Rory Walsh  wrote:
>>
>> Resource light looping? Tell us more. I'm sure we can hep you out.
>>
>> On 12 September 2014 22:17, Daisy Audio 
>> wrote:
>> > Evening all,
>> >
>> > A little while ago someone contacted me off list and said they had some
>> > nice
>> > resource light looping instrument code they'd send me. They never did
>> > and I
>> > can't recall who it was or find anything in my email.
>> >
>> > If this rings a bell with anyone, or anyone has anything along those
>> > lines,
>> > I'd love the files or text.
>> >
>> > Please either contact me directly or via the list as I'm sure others
>> > would
>> > find it useful.
>> >
>> > Thanks and have a good weekend.
>> >
>> > Dominic
>> >
>>
>>
>> Send bugs reports to
>>         https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>>
>>
>

Btw, did you catch the opcode I posted to the list a few days back? It
will auto-load all samples from a given directory into function tables
so you don't have to hard code any sample names. I find it pretty
useful for auditioning different sample packs. Are you really having
such a horrid time with the CPU? I can't think of any reason that Pd
would out perform Csound on this task. I think function tables are the
best way to go. If you pre-load samples on startup then it should be
as fast as you need. I found the thing that slowed my setup down was
the huge amount of events that I was spawning at pretty high
frequencies. But I'm sure I could tidy it up to run smoother.

On 14 September 2014 19:49, Daisy Audio  wrote:
>  I'm using function tables too. Same as you I found the file reading and
> player type opcodes weren't quick enough and aren't even consistent with
> their "speed". The same file could take a longer or shorter amount of time
> to be ready to play depending on the wind, ambient temperature etc ;)
> basically there was no pattern to it.
>
> I've got a really reliable, fast and quite CPU friendly PD looper I've made,
> but I'd rather move it all over to Csound if I can.
>
> How is anyone else dealing with audio loops? Are function tables pretty much
> the best realtime option?
>
> Might have to make a looper opcode as my first Csound opcode attempt.
> Certainly be an interesting and useful project.
>
> Cheers Rory for the input.
>
> Dominic
>
> On Saturday, September 13, 2014, Rory Walsh  wrote:
>>
>> How are you doing it at the moment? I usually just read from function
>> tables that load the loops on startup. I tried using some of the file
>> reading opcodes but they weren't fast enough. My largest sampler takes
>> a few moments to get everything in order on startup. But once
>> everything is loaded to RAM it's pretty quick. On the RPi you may need
>> to reduce the sampling rate. You will probably also have to experiment
>> with different ksmps values until you find the optimum one for the
>> system.
>>
>> On 13 September 2014 17:06, Daisy Audio 
>> wrote:
>> > Actually realised I didn't send the message I meant to the list
>> > originally.
>> > Doh!
>> >
>> > So, I'm basically looking for the least CPU intensive way of looping
>> > either
>> > prerecorded audio or live recorded audio or both ideally. Either would
>> > work.
>> > I know all the usual ways of achieving this, just wondered if anyone had
>> > found a lightweight, system resource friendly way of doing it.
>> >
>> > Ideally the less CPU I can use the better. Ram isn't an issue, so
>> > anything
>> > that simply calls the audio files into ram is fine, and usually far more
>> > responsive in live use.
>> >
>> > The overall file I use live is already battering my system so anything I
>> > can
>> > do to lighten the load would be extremely helpful!
>> >
>> > Currently running the live setup on OS X, but will be moving it over to
>> > Arch
>> > a Linux very soon, but don't think that'll change anything I can or
>> > can't
>> > use, hopefully!
>> >
>> > The eventual plan is to move the looping system onto a dedicated RPi
>> > that'll
>> > run nothing but Arch and the Csound looper.
>> >
>> > Thanks
>> >
>> > Dominic
>> >
>> >
>> > On Saturday, September 13, 2014, Rory Walsh  wrote:
>> >>
>> >> Resource light looping? Tell us more. I'm sure we can hep you out.
>> >>
>> >> On 12 September 2014 22:17, Daisy Audio 
>> >> wrote:
>> >> > Evening all,
>> >> >
>> >> > A little while ago someone contacted me off list and said they had
>> >> > some
>> >> > nice
>> >> > resource light looping instrument code they'd send me. They never did
>> >> > and I
>> >> > can't recall who it was or find anything in my email.
>> >> >
>> >> > If this rings a bell with anyone, or anyone has anything along those
>> >> > lines,
>> >> > I'd love the files or text.
>> >> >
>> >> > Please either contact me directly or via the list as I'm sure others
>> >> > would
>> >> > find it useful.
>> >> >
>> >> > Thanks and have a good weekend.
>> >> >
>> >> > Dominic
>> >> >
>> >>
>> >>
>> >> Send bugs reports to
>> >>         https://github.com/csound/csound/issues
>> >> Discussions of bugs and features can be posted here
>> >> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> >> "unsubscribe
>> >> csound"
>> >>
>> >>
>> >>
>> >
>>
>>
>> Send bugs reports to
>>         https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>>
>>
>

Have you all tried the --realtime flag to offload initialization to
another thread?  You might get a later note than expected but it
shouldn't break up audio then when doing a lot of processing on init.

On Mon, Sep 15, 2014 at 1:37 AM, Rory Walsh  wrote:
> Btw, did you catch the opcode I posted to the list a few days back? It
> will auto-load all samples from a given directory into function tables
> so you don't have to hard code any sample names. I find it pretty
> useful for auditioning different sample packs. Are you really having
> such a horrid time with the CPU? I can't think of any reason that Pd
> would out perform Csound on this task. I think function tables are the
> best way to go. If you pre-load samples on startup then it should be
> as fast as you need. I found the thing that slowed my setup down was
> the huge amount of events that I was spawning at pretty high
> frequencies. But I'm sure I could tidy it up to run smoother.
>
> On 14 September 2014 19:49, Daisy Audio  wrote:
>>  I'm using function tables too. Same as you I found the file reading and
>> player type opcodes weren't quick enough and aren't even consistent with
>> their "speed". The same file could take a longer or shorter amount of time
>> to be ready to play depending on the wind, ambient temperature etc ;)
>> basically there was no pattern to it.
>>
>> I've got a really reliable, fast and quite CPU friendly PD looper I've made,
>> but I'd rather move it all over to Csound if I can.
>>
>> How is anyone else dealing with audio loops? Are function tables pretty much
>> the best realtime option?
>>
>> Might have to make a looper opcode as my first Csound opcode attempt.
>> Certainly be an interesting and useful project.
>>
>> Cheers Rory for the input.
>>
>> Dominic
>>
>> On Saturday, September 13, 2014, Rory Walsh  wrote:
>>>
>>> How are you doing it at the moment? I usually just read from function
>>> tables that load the loops on startup. I tried using some of the file
>>> reading opcodes but they weren't fast enough. My largest sampler takes
>>> a few moments to get everything in order on startup. But once
>>> everything is loaded to RAM it's pretty quick. On the RPi you may need
>>> to reduce the sampling rate. You will probably also have to experiment
>>> with different ksmps values until you find the optimum one for the
>>> system.
>>>
>>> On 13 September 2014 17:06, Daisy Audio 
>>> wrote:
>>> > Actually realised I didn't send the message I meant to the list
>>> > originally.
>>> > Doh!
>>> >
>>> > So, I'm basically looking for the least CPU intensive way of looping
>>> > either
>>> > prerecorded audio or live recorded audio or both ideally. Either would
>>> > work.
>>> > I know all the usual ways of achieving this, just wondered if anyone had
>>> > found a lightweight, system resource friendly way of doing it.
>>> >
>>> > Ideally the less CPU I can use the better. Ram isn't an issue, so
>>> > anything
>>> > that simply calls the audio files into ram is fine, and usually far more
>>> > responsive in live use.
>>> >
>>> > The overall file I use live is already battering my system so anything I
>>> > can
>>> > do to lighten the load would be extremely helpful!
>>> >
>>> > Currently running the live setup on OS X, but will be moving it over to
>>> > Arch
>>> > a Linux very soon, but don't think that'll change anything I can or
>>> > can't
>>> > use, hopefully!
>>> >
>>> > The eventual plan is to move the looping system onto a dedicated RPi
>>> > that'll
>>> > run nothing but Arch and the Csound looper.
>>> >
>>> > Thanks
>>> >
>>> > Dominic
>>> >
>>> >
>>> > On Saturday, September 13, 2014, Rory Walsh  wrote:
>>> >>
>>> >> Resource light looping? Tell us more. I'm sure we can hep you out.
>>> >>
>>> >> On 12 September 2014 22:17, Daisy Audio 
>>> >> wrote:
>>> >> > Evening all,
>>> >> >
>>> >> > A little while ago someone contacted me off list and said they had
>>> >> > some
>>> >> > nice
>>> >> > resource light looping instrument code they'd send me. They never did
>>> >> > and I
>>> >> > can't recall who it was or find anything in my email.
>>> >> >
>>> >> > If this rings a bell with anyone, or anyone has anything along those
>>> >> > lines,
>>> >> > I'd love the files or text.
>>> >> >
>>> >> > Please either contact me directly or via the list as I'm sure others
>>> >> > would
>>> >> > find it useful.
>>> >> >
>>> >> > Thanks and have a good weekend.
>>> >> >
>>> >> > Dominic
>>> >> >
>>> >>
>>> >>
>>> >> Send bugs reports to
>>> >>         https://github.com/csound/csound/issues
>>> >> Discussions of bugs and features can be posted here
>>> >> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>> >> "unsubscribe
>>> >> csound"
>>> >>
>>> >>
>>> >>
>>> >
>>>
>>>
>>> Send bugs reports to
>>>         https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>>
>>>
>>
>
>
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>
>

i'm working on a looper, modelled after tape loops. i've finally got
around to posting something on github:

https://github.com/khirai/tape_echo

nothing is prerecorded. its an effects processor. has independently
controlled variable speed playback and record heads. all run with tab
and phasor. alias artefacts when the sample rates get low or mismatched.
i'm currently working on saving parameters between runs and changing
tapes. controlled by the korg kontrol one.

sound samples on soundcloud here.
https://soundcloud.com/kghongaku/tape-echo-amps

work in progress.
k.

On 09/14/2014 06:40 PM, Steven Yi wrote:
> Have you all tried the --realtime flag to offload initialization to
> another thread?  You might get a later note than expected but it
> shouldn't break up audio then when doing a lot of processing on init.
>
> On Mon, Sep 15, 2014 at 1:37 AM, Rory Walsh  wrote:
>> Btw, did you catch the opcode I posted to the list a few days back? It
>> will auto-load all samples from a given directory into function tables
>> so you don't have to hard code any sample names. I find it pretty
>> useful for auditioning different sample packs. Are you really having
>> such a horrid time with the CPU? I can't think of any reason that Pd
>> would out perform Csound on this task. I think function tables are the
>> best way to go. If you pre-load samples on startup then it should be
>> as fast as you need. I found the thing that slowed my setup down was
>> the huge amount of events that I was spawning at pretty high
>> frequencies. But I'm sure I could tidy it up to run smoother.
>>
>> On 14 September 2014 19:49, Daisy Audio  wrote:
>>>  I'm using function tables too. Same as you I found the file reading and
>>> player type opcodes weren't quick enough and aren't even consistent with
>>> their "speed". The same file could take a longer or shorter amount of time
>>> to be ready to play depending on the wind, ambient temperature etc ;)
>>> basically there was no pattern to it.
>>>
>>> I've got a really reliable, fast and quite CPU friendly PD looper I've made,
>>> but I'd rather move it all over to Csound if I can.
>>>
>>> How is anyone else dealing with audio loops? Are function tables pretty much
>>> the best realtime option?
>>>
>>> Might have to make a looper opcode as my first Csound opcode attempt.
>>> Certainly be an interesting and useful project.
>>>
>>> Cheers Rory for the input.
>>>
>>> Dominic
>>>
>>> On Saturday, September 13, 2014, Rory Walsh  wrote:
>>>> How are you doing it at the moment? I usually just read from function
>>>> tables that load the loops on startup. I tried using some of the file
>>>> reading opcodes but they weren't fast enough. My largest sampler takes
>>>> a few moments to get everything in order on startup. But once
>>>> everything is loaded to RAM it's pretty quick. On the RPi you may need
>>>> to reduce the sampling rate. You will probably also have to experiment
>>>> with different ksmps values until you find the optimum one for the
>>>> system.
>>>>
>>>> On 13 September 2014 17:06, Daisy Audio 
>>>> wrote:
>>>>> Actually realised I didn't send the message I meant to the list
>>>>> originally.
>>>>> Doh!
>>>>>
>>>>> So, I'm basically looking for the least CPU intensive way of looping
>>>>> either
>>>>> prerecorded audio or live recorded audio or both ideally. Either would
>>>>> work.
>>>>> I know all the usual ways of achieving this, just wondered if anyone had
>>>>> found a lightweight, system resource friendly way of doing it.
>>>>>
>>>>> Ideally the less CPU I can use the better. Ram isn't an issue, so
>>>>> anything
>>>>> that simply calls the audio files into ram is fine, and usually far more
>>>>> responsive in live use.
>>>>>
>>>>> The overall file I use live is already battering my system so anything I
>>>>> can
>>>>> do to lighten the load would be extremely helpful!
>>>>>
>>>>> Currently running the live setup on OS X, but will be moving it over to
>>>>> Arch
>>>>> a Linux very soon, but don't think that'll change anything I can or
>>>>> can't
>>>>> use, hopefully!
>>>>>
>>>>> The eventual plan is to move the looping system onto a dedicated RPi
>>>>> that'll
>>>>> run nothing but Arch and the Csound looper.
>>>>>
>>>>> Thanks
>>>>>
>>>>> Dominic
>>>>>
>>>>>
>>>>> On Saturday, September 13, 2014, Rory Walsh  wrote:
>>>>>> Resource light looping? Tell us more. I'm sure we can hep you out.
>>>>>>
>>>>>> On 12 September 2014 22:17, Daisy Audio 
>>>>>> wrote:
>>>>>>> Evening all,
>>>>>>>
>>>>>>> A little while ago someone contacted me off list and said they had
>>>>>>> some
>>>>>>> nice
>>>>>>> resource light looping instrument code they'd send me. They never did
>>>>>>> and I
>>>>>>> can't recall who it was or find anything in my email.
>>>>>>>
>>>>>>> If this rings a bell with anyone, or anyone has anything along those
>>>>>>> lines,
>>>>>>> I'd love the files or text.
>>>>>>>
>>>>>>> Please either contact me directly or via the list as I'm sure others
>>>>>>> would
>>>>>>> find it useful.
>>>>>>>
>>>>>>> Thanks and have a good weekend.
>>>>>>>
>>>>>>> Dominic
>>>>>>>
>>>>>>
>>>>>> Send bugs reports to
>>>>>>         https://github.com/csound/csound/issues
>>>>>> Discussions of bugs and features can be posted here
>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>>>> "unsubscribe
>>>>>> csound"
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>> Send bugs reports to
>>>>         https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>>
>>>>
>>>>
>>
>> Send bugs reports to
>>         https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>
>>
>
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>
>

You're on Linux right? Just add to cmakelist.txt in the Opcodes dir..

make_plugin(ftsamplebank ftsampleank.cpp)

On 15 September 2014 22:41, Daisy Audio  wrote:
> That sounds cool Kelly, I'll check it out.
>
> Rory, I don't think PD outperforms Csound per say, I think it's just I have
> a lot more experience with looping in PD and Max/MSP so I can tweak and
> refine the patch a lot more than I can with Csound. Also the way audio file
> objects behave helps, but again I know them far better.
>
> And no I don't think I saw the opcode you posted, have you got a link?
>
> Steven I'll have a play with the flags and see what I can squeeze out of it.
>
> I'll have to do more research with Csound looping and see what I come up
> with. It's been a while.
>
>
> Thanks for all the input.
>
> Dominic
>
>
> On Monday, September 15, 2014, Kelly Hirai 
> wrote:
>>
>> i'm working on a looper, modelled after tape loops. i've finally got
>> around to posting something on github:
>>
>> https://github.com/khirai/tape_echo
>>
>> nothing is prerecorded. its an effects processor. has independently
>> controlled variable speed playback and record heads. all run with tab
>> and phasor. alias artefacts when the sample rates get low or mismatched.
>> i'm currently working on saving parameters between runs and changing
>> tapes. controlled by the korg kontrol one.
>>
>> sound samples on soundcloud here.
>> https://soundcloud.com/kghongaku/tape-echo-amps
>>
>> work in progress.
>> k.
>>
>> On 09/14/2014 06:40 PM, Steven Yi wrote:
>> > Have you all tried the --realtime flag to offload initialization to
>> > another thread?  You might get a later note than expected but it
>> > shouldn't break up audio then when doing a lot of processing on init.
>> >
>> > On Mon, Sep 15, 2014 at 1:37 AM, Rory Walsh  wrote:
>> >> Btw, did you catch the opcode I posted to the list a few days back? It
>> >> will auto-load all samples from a given directory into function tables
>> >> so you don't have to hard code any sample names. I find it pretty
>> >> useful for auditioning different sample packs. Are you really having
>> >> such a horrid time with the CPU? I can't think of any reason that Pd
>> >> would out perform Csound on this task. I think function tables are the
>> >> best way to go. If you pre-load samples on startup then it should be
>> >> as fast as you need. I found the thing that slowed my setup down was
>> >> the huge amount of events that I was spawning at pretty high
>> >> frequencies. But I'm sure I could tidy it up to run smoother.
>> >>
>> >> On 14 September 2014 19:49, Daisy Audio 
>> >> wrote:
>> >>>  I'm using function tables too. Same as you I found the file reading
>> >>> and
>> >>> player type opcodes weren't quick enough and aren't even consistent
>> >>> with
>> >>> their "speed". The same file could take a longer or shorter amount of
>> >>> time
>> >>> to be ready to play depending on the wind, ambient temperature etc ;)
>> >>> basically there was no pattern to it.
>> >>>
>> >>> I've got a really reliable, fast and quite CPU friendly PD looper I've
>> >>> made,
>> >>> but I'd rather move it all over to Csound if I can.
>> >>>
>> >>> How is anyone else dealing with audio loops? Are function tables
>> >>> pretty much
>> >>> the best realtime option?
>> >>>
>> >>> Might have to make a looper opcode as my first Csound opcode attempt.
>> >>> Certainly be an interesting and useful project.
>> >>>
>> >>> Cheers Rory for the input.
>> >>>
>> >>> Dominic
>> >>>
>> >>> On Saturday, September 13, 2014, Rory Walsh  wrote:
>> >>>> How are you doing it at the moment? I usually just read from function
>> >>>> tables that load the loops on startup. I tried using some of the file
>> >>>> reading opcodes but they weren't fast enough. My largest sampler
>> >>>> takes
>> >>>> a few moments to get everything in order on startup. But once
>> >>>> everything is loaded to RAM it's pretty quick. On the RPi you may
>> >>>> need
>> >>>> to reduce the sampling rate. You will probably also have to
>> >>>> experiment
>> >>>> with different ksmps values until you find the optimum one for the
>> >>>> system.
>> >>>>
>> >>>> On 13 September 2014 17:06, Daisy Audio
>> >>>> 
>> >>>> wrote:
>> >>>>> Actually realised I didn't send the message I meant to the list
>> >>>>> originally.
>> >>>>> Doh!
>> >>>>>
>> >>>>> So, I'm basically looking for the least CPU intensive way of looping
>> >>>>> either
>> >>>>> prerecorded audio or live recorded audio or both ideally. Either
>> >>>>> would
>> >>>>> work.
>> >>>>> I know all the usual ways of achieving this, just wondered if anyone
>> >>>>> had
>> >>>>> found a lightweight, system resource friendly way of doing it.
>> >>>>>
>> >>>>> Ideally the less CPU I can use the better. Ram isn't an issue, so
>> >>>>> anything
>> >>>>> that simply calls the audio files into ram is fine, and usually far
>> >>>>> more
>> >>>>> responsive in live use.
>> >>>>>
>> >>>>> The overall file I use live is already battering my system so
>> >>>>> anything I
>> >>>>> can
>> >>>>> do to lighten the load would be extremely helpful!
>> >>>>>
>> >>>>> Currently running the live setup on OS X, but will be moving it over
>> >>>>> to
>> >>>>> Arch
>> >>>>> a Linux very soon, but don't think that'll change anything I can or
>> >>>>> can't
>> >>>>> use, hopefully!
>> >>>>>
>> >>>>> The eventual plan is to move the looping system onto a dedicated RPi
>> >>>>> that'll
>> >>>>> run nothing but Arch and the Csound looper.
>> >>>>>
>> >>>>> Thanks
>> >>>>>
>> >>>>> Dominic
>> >>>>>
>> >>>>>
>> >>>>> On Saturday, September 13, 2014, Rory Walsh 
>> >>>>> wrote:
>> >>>>>> Resource light looping? Tell us more. I'm sure we can hep you out.
>> >>>>>>
>> >>>>>> On 12 September 2014 22:17, Daisy Audio
>> >>>>>> 
>> >>>>>> wrote:
>> >>>>>>> Evening all,
>> >>>>>>>
>> >>>>>>> A little while ago someone contacted me off list and said they had
>> >>>>>>> some
>> >>>>>>> nice
>> >>>>>>> resource light looping instrument code they'd send me. They never
>> >>>>>>> did
>> >>>>>>> and I
>> >>>>>>> can't recall who it was or find anything in my email.
>> >>>>>>>
>> >>>>>>> If this rings a bell with anyone, or anyone has anything along
>> >>>>>>> those
>> >>>>>>> lines,
>> >>>>>>> I'd love the files or text.
>> >>>>>>>
>> >>>>>>> Please either contact me directly or via the list as I'm sure
>> >>>>>>> others
>> >>>>>>> would
>> >>>>>>> find it useful.
>> >>>>>>>
>> >>>>>>> Thanks and have a good weekend.
>> >>>>>>>
>> >>>>>>> Dominic
>> >>>>>>>
>> >>>>>>
>> >>>>>> Send bugs reports to
>> >>>>>>         https://github.com/csound/csound/issues
>> >>>>>> Discussions of bugs and features can be posted here
>> >>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> >>>>>> "unsubscribe
>> >>>>>> csound"
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>
>> >>>> Send bugs reports to
>> >>>>         https://github.com/csound/csound/issues
>> >>>> Discussions of bugs and features can be posted here
>> >>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> >>>> "unsubscribe
>> >>>> csound"
>> >>>>
>> >>>>
>> >>>>
>> >>
>> >> Send bugs reports to
>> >>         https://github.com/csound/csound/issues
>> >> Discussions of bugs and features can be posted here
>> >> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> >> "unsubscribe csound"
>> >>
>> >>
>> >>
>> >
>> > Send bugs reports to
>> >         https://github.com/csound/csound/issues
>> > Discussions of bugs and features can be posted here
>> > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> > csound"
>> >
>> >
>> >
>>
>>
>>
>> Send bugs reports to
>>         https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>>
>>
>