[CM] problems with cm3

[lieven moors]

Heinrich Taube wrote:
> the code you sent me incorrect for realtime scheduling and when i 
> correct it things work. the issue is your time stamps -- in realtime a 
> time stamp is interpreted as an AHEAD factor, so when you pass it the 
> value of (elapsed) you are telling it to play that many seconds in the 
> future. when i remove that time stamp things work in either case 
> everything plays in lock-step for me.
>
> (define (algo02 dur row beat amp chan)
> (process while (< (elapsed ) dur)
>     with range = (length row)
>     for d = beat
>     for k = (list-ref row chan)
>     for a = (between 0.1 amp)
>     for w = d
>     do (send "mp:midi" :dur d  :key k :amp .8 :chan chan)
>          (wait w)))
>
> (sprout (list (algo02 16 keyscale .25 1.0 0)
>              (algo02 14 keyscale .25 1.0 1)
>              (algo02 12 keyscale .25 1.0 2)
>              (algo02 10 keyscale .25 1.0 3))
>
> even at 10 times the lenth (160 seconds) I dont notice any drift.
>
>
Well, this doesn't work for me. I' ve tried a hundred times without
adding timestamps,
and because I always had the drift, I tried adding timestamps later on.
I' ve tried this on my laptop, both with the stock ubuntu kernel
(2.6.27.11) and with the latest realtime patched kernel (2.6.29.1). When
I use the first, I 'm having dropouts as well, although I think my
laptop should be more than fast enough to run cm without any problems.
The dropouts seems to go away with the realtime kernel. But in both
cases I have a significant drift.
As I said before, I tested all this (without adding timestamps), with
very simple algorithms on my 64bit machine running Ubuntu Studio (hardy
with realtime kernel) as well. I don't have dropouts on that machine,
but the drift is very clear. I wrote a simpler test function as a reference.

(define keyscale (scale 4 60 '(4 3 5)))

(define (test scale index beat)
  (process while (< (elapsed) 10)
           for k = (list-ref scale index)
           do (send "mp:midi" :dur (rhythm 'x) :key k)
           (wait beat)))

(sprout (list (test keyscale 0 0.25)
              (test keyscale 1 0.25)
              (test keyscale 2 0.25)))


>> >Another problem I have is when i'm sprouting to a midi file. When I 
>> write a file which according to the scheduler is 120 seconds long
>
> when I write a midifile it plays exactly the same in quicktime and i 
> can import it into sibelius and notator logic
>
> (sprout (list (algo02 16 keyscale .25 1.0 0)
>              (algo02 14 keyscale .25 1.0 1)
>              (algo02 12 keyscale .25 1.0 2)
>              (algo02 10 keyscale .25 1.0 3))
>        4 "hkt.mid")
>
When I do this with the above (simpler) code:

(sprout (list (test keyscale 0 0.25)
              (test keyscale 1 0.25)
              (test keyscale 2 0.25)) "test.mid")

and when I open the midi file in rosegarden, the time values of the
three notes that are played together are in sync, but the distance
between the respective chords is reported as 2 miliseconds. I remember
having the same result in my studio.

>
> In general dont use time stamps, the only time you need a time stamp 
> is if you call an fm instrument -- the instrument wants to know the 
> true time to write the audio indo the file (fm-violin (elapsed #t )
>
>> I also have problems when I use Grace to save (scheme) files. When I try
>> to commit my changes using git, git suddenly complains about lots of
>> trailing whitespaces.
>
> i dont know what 'git' is.  when i open a grace file in emacs it looks 
> exactly like it does it grace.
>
Git is the Version Control System used for the linux kernel (written by
Linus himself) and numerous other open source projects. I only have
these mysterious invisible whitespaces when I saved a file with Grace
(not with vim or emacs), so I suspect something is wrong.
>
> bottom line: im using cm 3.2.4 (svn trunk) and things seem to be work 
> well .
>
>

I downloaded my version (the same version number) quite recently as a
tarball. I could try the svn version, and see if that helps.

I'm prepared to go to the bottom of this, so if you have any suggestions
for testing this (e.g. insert bits of debugging code), I will take my
time for this.

Thanks,

Lieven