I'm getting strange (not good) results with the SF_Record example bundled in
CsoundQt 0.8.0 for Windows.

First, it appears the time readout in the Widgets window is running at
half-speed or less. One second on the time readout feels like two seconds or
three. By itself this is not important, but it's probably significant.

The audible problem is that when I open the recorded file in Audacity, it
has grungy artifacts and plays back at the original pitch but two or three
times the tempo! I'm recording a slowly panning tone from my modular
hardware synth, and the panning rate in the recorded file is definitely much
faster compared to what the synth is actually doing. The file length as
displayed in Audacity's time ruler is what the SF_Record time counter
indicates.

My best guess is that SF_Record is dropping about 2/3 of the samples.

The result is the same whether I record 24-bit or 16-bit WAV.

Also, the Console reports that instr 102 has 20 p-fields, but only uses
four. I assume this is probably not significant, as the code uses p(ipfld),
which is presumably (I've never used it) a way of reading the other p-fields
iteratively. I mention this message only for the sake of completeness.

Aside from reporting that the example needs to be cleaned up, I'm concerned
because I'd like to be able to record audio directly into Csound and from
there onto the hard drive, and this example seemed to be the right place to
start....



--
View this message in context: http://csound.1045644.n5.nabble.com/SF-Record-Example-CsoundQt-tp5730528.html
Sent from the Csound - General mailing list archive at Nabble.com.

...but wait, there's more. The SF_Record .csd has ksmps=128. Noticing that my
recorded file was obviously stair-stepped at something like that rate, I
thought, oh, maybe if I reduce ksmps to 8, it will smooth out the recording.

Setting ksmps down to 8 makes the problem much, much worse. Now the time
readout simply creeps along -- a six- or eight-second recording doesn't even
reach the 1-second mark in the readout, and the resulting soundfile is,
indeed, less than 1 second long.



--
View this message in context: http://csound.1045644.n5.nabble.com/SF-Record-Example-CsoundQt-tp5730528p5730529.html
Sent from the Csound - General mailing list archive at Nabble.com.

thanks very much for the report. i tested this under linux and found 
that there is a heavy cpu overload. the example works, but because of 
this, i get distortions as well.

perhaps this is the reason for your problems, too? do you also get 
something like:
real: 25.619s, CPU: 24.640s
?

the warning about the p-fields is ok, but i will have a look in this 
example, to see if i can improve the code not to get such a cpu overload.

best -

	joachim


Am 03.12.2013 22:55, schrieb Jim Aikin:
> ...but wait, there's more. The SF_Record .csd has ksmps=128. Noticing that my
> recorded file was obviously stair-stepped at something like that rate, I
> thought, oh, maybe if I reduce ksmps to 8, it will smooth out the recording.
>
> Setting ksmps down to 8 makes the problem much, much worse. Now the time
> readout simply creeps along -- a six- or eight-second recording doesn't even
> reach the 1-second mark in the readout, and the resulting soundfile is,
> indeed, less than 1 second long.
>
>
>
> --
> View this message in context: http://csound.1045644.n5.nabble.com/SF-Record-Example-CsoundQt-tp5730528p5730529.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
> Send bugs reports to the Sourceforge bug trackers
> csound6:
>              https://sourceforge.net/p/csound/tickets/
> csound5:
>              https://sourceforge.net/p/csound/bugs/
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>
>

> perhaps this is the reason for your problems, too? do you also get
> something like:
> real: 25.619s, CPU: 24.640s
> ? 

The Console output always reports that real elapsed time and CPU elapsed
time are the same (or CPU is about 1ms longer). This happens with even
simple synthesis processes that are using very little CPU, and it's no
different with SF_Record. So I can't answer your question, sorry.



--
View this message in context: http://csound.1045644.n5.nabble.com/SF-Record-Example-CsoundQt-tp5730528p5730550.html
Sent from the Csound - General mailing list archive at Nabble.com.

hi jim -

i made a new version of the SF_Record example in csoundqt. it uses 
chnget/chnset instead of invalue/outvalue. this gives an immense 
increase in performance for me.

the new code is attached. if you can try, i will be thankful. (other 
testers are very much welcome as well of course.)

all best -

	joachim



Am 04.12.2013 18:18, schrieb Jim Aikin:
>> perhaps this is the reason for your problems, too? do you also get
>> something like:
>> real: 25.619s, CPU: 24.640s
>> ?
>
> The Console output always reports that real elapsed time and CPU elapsed
> time are the same (or CPU is about 1ms longer). This happens with even
> simple synthesis processes that are using very little CPU, and it's no
> different with SF_Record. So I can't answer your question, sorry.
>
>
>
> --
> View this message in context: http://csound.1045644.n5.nabble.com/SF-Record-Example-CsoundQt-tp5730528p5730550.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
> Send bugs reports to the Sourceforge bug trackers
> csound6:
>              https://sourceforge.net/p/csound/tickets/
> csound5:
>              https://sourceforge.net/p/csound/bugs/
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>
>