trouble with saw_c

[dsp1986]

while following the guides, to get to know the environment I came accross the need of a saw_c unit generator. I couldn't find it anywhere, so I took it as an exercise to write my own. I came up with:

(bind-func saw_c
  (lambda (phase)
    (lambda (amp freq:SAMPLE)
      (let ((incr (/ freq 44100.0)))
	(set! phase (% (+ phase incr) 1.0))
	(* amp (- (* 2 phase) 1))))))

however, on compilation I get a type error:

Type Error conflicting i64 with float in (+ phase incr)

I don't understand why extempore thinks phase should be an i64?
Up to this point all examples in philosphy and the guide have worked.

Any ideas?

[digego]

In xtlang integer literals are typed as i64 by default, so in this instance 'phase' is typed as i64 because of (* 2 phase). This then conflicts with 'incr' which is typed SAMPLE. If you change your 2 to 2.0 and the 1 to 1.0 you should be good ;)

…

On Wed, Nov 14, 2018 at 10:50 PM dsp1986 ***@***.***> wrote: while following the guides, to get to know the environment I came accross the need of a saw_c unit generator. I couldn't find it anywhere, so I took it as an exercise to write my own. I came up with: (bind-func saw_c (lambda (phase) (lambda (amp freq:SAMPLE) (let ((incr (/ freq 44100.0))) (set! phase (% (+ phase incr) 1.0)) (* amp (- (* 2 phase) 1)))))) however, on compilation I get a type error: Type Error conflicting i64 with float in (+ phase incr) I don't understand why extempore thinks phase should be an i64? Up to this point all examples in philosphy and the guide have worked. Any ideas? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#17>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAh3qWMO69MSoqheaejHPeH7U_cHnyaNks5uvBGXgaJpZM4YdrWY> .

[dsp1986]

that did the trick. Thank you!
weird though, that the compiler complained about a bit of code that was perfectly fine, while the actual error was somewhere else...

[digego]

the 'bit of code' was not perfectly fine because the compiler was trying to (+ phase:i64 incr:SAMPLE) -- so the error was correct and pointed to the 'bad' code. The line (* 2 phase) *is* perfectly fine, but causes the compiler to type phase as i64. This then has the (unintended in your case) consequence of forcing phase to i64. You might reasonably question why (+ phase incr) doesn't force the phase to SAMPLE, and the answer to that is that it would except that a literal 2 (2:i64) takes precedence when resolving the type so (* 2 phase) takes precedence for type resolution over (+ phase incr). Now, all that said, I 100% agree that we would like better error messages from the xtlang compiler - onwards and upwards :) What you should try to keep in mind from this example though is that literals have a high precedence when resolving types.

…

On Sun, Nov 18, 2018 at 10:54 AM dsp1986 ***@***.***> wrote: that did the trick. Thank you! weird though, that the compiler complained about a bit of code that was perfectly fine, while the actual error was somewhere else... — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#17 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAh3qT7To0YrukJreahiNHwE4qk7i0t-ks5uwK-xgaJpZM4YdrWY> .