Re: [haskell-art] Re: Creating .wav or .aiff with SuperCollider/HSC3
On Mon, 13 Aug 2007, Rohan Drape wrote: > this all works here, apart from the fixed SR in the > audio file, which does not correspond to the SR that > scsynth runs at (-S doesn't seem to help, but > whatever...) > > your osc file and the generated file are equal, > at least according to cmp... > > ~$ cmp tone.osc ht-tone.osc > ~$ > > not sure what the matter can be, a bad scsynth seems > unlikely, but what else... maybe we ought to take > this off-list? I think the solution will be of interest for users who run into this problem in the future. My SuperCollider is from an RPM package with version number 3.0_cvs20040823, so maybe an update will help. ___ haskell-art mailing list [email protected] http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Re: Creating .wav or .aiff with SuperCollider/HSC3
this all works here, apart from the fixed SR in the audio file, which does not correspond to the SR that scsynth runs at (-S doesn't seem to help, but whatever...) your osc file and the generated file are equal, at least according to cmp... ~$ cmp tone.osc ht-tone.osc ~$ not sure what the matter can be, a bad scsynth seems unlikely, but what else... maybe we ought to take this off-list? ___ haskell-art mailing list [email protected] http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Re: Creating .wav or .aiff with SuperCollider/HSC3
I have still no luck. I installed latest hosc and hsc3 from darcs repo,
tried the attached example program which uses the new function writeNRT,
and got the following output
$ ghci NonRealtime.hs
*Main> nonrealtime
Loading package fps-0.8 ... linking ... done.
Loading package binary-0.2 ... linking ... done.
Loading package parsec-1.0 ... linking ... done.
Loading package network-1.0 ... linking ... done.
Loading package hosc-0.1 ... linking ... done.
Loading package hsc3-0.1 ... linking ... done.
Using Altivec: no
*** ERROR: open directory failed 'synthdefs'
start time 0
*Main> :! ls -al tone.*
-rw--- 1 thielema users 182 2007-08-12 19:19 tone.aiff
-rw--- 1 thielema users 256 2007-08-12 19:19 tone.osc
See the attached OSC file in order to see if it matches the one you can
produce. If my OSC file matches yours then something with my SCSynth is
wrong, if it does not match, maybe ByteString or Binary is wrong.
Thanks for the help!
{-
This module tries to reproduce results of the real-time synthesizer
in scsynth's non-real-time mode.
-}
import Sound.OpenSoundControl(OSC(Bundle))
import Sound.OpenSoundControl.Byte (encode_i32)
import Sound.OpenSoundControl.Time(utc)
import Sound.OpenSoundControl.Transport(send)
import Sound.SC3
import Sound.SC3.Server.NRT (writeNRT)
import qualified Sound.SC3.Server.Play as Play
import qualified Data.ByteString.Lazy as B
import System.Cmd (rawSystem)
beep = out 0 (sinOsc AR 440 0)
name ="Beep"
installSound n = d_recv . graphdef n . graph
bundle start t = Bundle (start+t)
rootId = 0
homeId = 1
autoId = -1
latency = 0.1
msgs :: [(Double, [OSC])]
msgs =
(0, g_freeAll [rootId] :
g_new [(homeId, AddToTail, rootId)] :
installSound name beep :
s_new name autoId AddToTail homeId [] :
[]) :
(1, g_freeAll [homeId] :
[]) :
[]
attachTimeStamps :: [(Double, [OSC])] -> IO [OSC]
attachTimeStamps ms =
do now <- utc
return (map (uncurry (bundle (now+latency))) ms)
realtime =
Play.withSC3 $ \fd ->
mapM (send fd) =<< attachTimeStamps msgs
oscFileName = "tone.osc"
nonrealtime =
do let tsMsgs = map (uncurry Bundle) msgs
writeNRT oscFileName tsMsgs
rawSystem "scsynth"
["-o", "1", "-N", oscFileName, "_", "tone.aiff",
"44100", "AIFF", "int16"]
main =
realtime >>
nonrealtime
tone.osc
Description: Binary data
tone.aiff
Description: audio/aiff
___
haskell-art mailing list
[email protected]
http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Re: Creating .wav or .aiff with SuperCollider/HSC3
Henning Thielemann <[EMAIL PROTECTED]> writes: > But I indeed mean 'zero based'. Since scsynth doesn't know about Haskell's > OSC type we can use any time base, and I think time base 0 is the most > natural one. The actual time base needed for scsynth is added when > encoding the message. the meaning of the bundle timestamp is given by the osc specification, not by scsynth. hosc shifts the epoch from 1900-01-01 to 1970-01-01 because that is what system clocks use, and from a (32+32)bit integer representation to a double because it makes the math simpler. this is, i think, pretty standard practice in osc libraries. in any case that is the hosc model. > Today we write something like this > do now <- utc > let msg = Bundle (now+effectStartTime) effect > send fd (encodeOSC msg) perhaps, however there are a _lot_ of ways to arrange scheduling, hosc and hsc3 are deliberately agnostic about this. > This has also the advantage that generation of scores does not depend on a > IO generated value (namely 'now'). osc does not have a notion of 'score'. the scsynth notion is a minor abuse/extension of the osc protocol. i imagine the scsynth requirement to start at ntp 'zero' is so that scores do not need to contain a 'nil' event if the initial 'actual' event is non-zero. (i'd prefer that scsynth accept any starting time, but can see both sides of that coin). rd ___ haskell-art mailing list [email protected] http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Re: Creating .wav or .aiff with SuperCollider/HSC3
On Sun, 12 Aug 2007, Rohan Drape wrote: > Henning Thielemann <[EMAIL PROTECTED]> writes: > > We need > > encodeOSCZeroBase :: OSC -> B.ByteString > > which converts a message by converting Double to Integer > > and does the message encoding (which is currently done by encodeOSC) > > delayOSC :: Double -> OSC -> OSC > > which shifts a message in time (i.e. changes time base) > > encodeOSC :: Double -> OSC -> B.ByteString > > calls delayOSC and encodeOSCZeroBase > > > > encodeOSCZeroBase can be used for non-realtime synthesis and encodeOSC for > > realtime use. > > i'm not sure about this. encodeOSC uses the conventional > 'unix/utc' epoch. encodeOSCZeroBase would not be 'zero' > it would be the rather more obscure 'ntp epoch'. But I indeed mean 'zero based'. Since scsynth doesn't know about Haskell's OSC type we can use any time base, and I think time base 0 is the most natural one. The actual time base needed for scsynth is added when encoding the message. Today we write something like this do now <- utc let msg = Bundle (now+effectStartTime) effect send fd (encodeOSC msg) With my proposed change we would write do let msg = Bundle effectStartTime effect now <- utc send fd (encodeOSC now msg) This has also the advantage that generation of scores does not depend on a IO generated value (namely 'now'). ___ haskell-art mailing list [email protected] http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Re: Creating .wav or .aiff with SuperCollider/HSC3
> Henning Thielemann <[EMAIL PROTECTED]> writes: >> We need >> encodeOSCZeroBase :: OSC -> B.ByteString >> which converts a message by converting Double to Integer >> and does the message encoding (which is currently done by encodeOSC) >> delayOSC :: Double -> OSC -> OSC >> which shifts a message in time (i.e. changes time base) >> encodeOSC :: Double -> OSC -> B.ByteString >> calls delayOSC and encodeOSCZeroBase actually, decided this is ok, hosc now also exports 'encodeOSC_NTP' for ntp epoch time-stamps. hsc3 encodeNRT now relies on that. hope that helps. rd ___ haskell-art mailing list [email protected] http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Re: Creating .wav or .aiff with SuperCollider/HSC3
Henning Thielemann <[EMAIL PROTECTED]> writes: > We need > encodeOSCZeroBase :: OSC -> B.ByteString > which converts a message by converting Double to Integer > and does the message encoding (which is currently done by encodeOSC) > delayOSC :: Double -> OSC -> OSC > which shifts a message in time (i.e. changes time base) > encodeOSC :: Double -> OSC -> B.ByteString > calls delayOSC and encodeOSCZeroBase > > encodeOSCZeroBase can be used for non-realtime synthesis and encodeOSC for > realtime use. i'm not sure about this. encodeOSC uses the conventional 'unix/utc' epoch. encodeOSCZeroBase would not be 'zero' it would be the rather more obscure 'ntp epoch'. it just happens that scsynth requires that nrt scores begin on the first of january 1900. i think a better idea would be to patch scsynth to work with relative timestamps so scores could start at any absolute time. (ie. at first january 1970, in which case you could write scores starting at utc/unix zero). rd ___ haskell-art mailing list [email protected] http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Re: Creating .wav or .aiff with SuperCollider/HSC3
On Sat, 11 Aug 2007, Rohan Drape wrote: > Henning Thielemann <[EMAIL PROTECTED]> writes: > > However I consider it a slight hack to first add magic number 2208988800 > > in utc_ntp, then subtract it in ntpZeroed again. Would you mind making the > > Bundle time zero based and add the appropriate offset at encoding the > > message? > > 2208988800 = (70 * 365 + 17) * 24 * 60 * 60 > NTP epoch = January 1, 1900 > Unix/UTC epoch = January 1, 1970 > > Deleting the -/+ would mean making a local variant > of encodeOSC and I'm not sure it is really important? > (ie. I don't this this is going to slow anything > down too much?) We need encodeOSCZeroBase :: OSC -> B.ByteString which converts a message by converting Double to Integer and does the message encoding (which is currently done by encodeOSC) delayOSC :: Double -> OSC -> OSC which shifts a message in time (i.e. changes time base) encodeOSC :: Double -> OSC -> B.ByteString calls delayOSC and encodeOSCZeroBase encodeOSCZeroBase can be used for non-realtime synthesis and encodeOSC for realtime use. ___ haskell-art mailing list [email protected] http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Re: Creating .wav or .aiff with SuperCollider/HSC3
Henning Thielemann <[EMAIL PROTECTED]> writes: > However I consider it a slight hack to first add magic number 2208988800 > in utc_ntp, then subtract it in ntpZeroed again. Would you mind making the > Bundle time zero based and add the appropriate offset at encoding the > message? 2208988800 = (70 * 365 + 17) * 24 * 60 * 60 NTP epoch = January 1, 1900 Unix/UTC epoch = January 1, 1970 Deleting the -/+ would mean making a local variant of encodeOSC and I'm not sure it is really important? (ie. I don't this this is going to slow anything down too much?) All timestamps are zero based, it is just a matter of when the zero was :) The integer OSC NTP time format is not very nice at user level so the convention is to us real-valued UTC times. > Btw. Sound.SC3.Server.Private.mkDuples should be mkPairs ? I thought that duple and pair were synonyms in this context? It seems perhaps not very common, google does show some uses given 'duple 2-tuple'. > Your example didn't work here (message length >8192 error), but let me > incorporate and test with your past patches before worrying about it. :-) OK, I've not seen any message length errors here. ___ haskell-art mailing list [email protected] http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Re: Creating .wav or .aiff with SuperCollider/HSC3
On Sat, 11 Aug 2007, Rohan Drape wrote: > Henning Thielemann <[EMAIL PROTECTED]> writes: > > I boiled the problems down to a simple example. There are no errors > > reported about the messages, but the result is not what we expect. > > I've added encodeNRT and writeNRT to hsc3, these ought to work out of > the box. Nice, that's what I was about to ask you. :-) However I consider it a slight hack to first add magic number 2208988800 in utc_ntp, then subtract it in ntpZeroed again. Would you mind making the Bundle time zero based and add the appropriate offset at encoding the message? Btw. Sound.SC3.Server.Private.mkDuples should be mkPairs ? > Let me know if that helps. (They are in Sound.SC3.Server.NRT, but > exported from Sound.SC3.Server and Sound.SC3) Your example didn't work here (message length >8192 error), but let me incorporate and test with your past patches before worrying about it. :-) ___ haskell-art mailing list [email protected] http://lists.lurk.org/mailman/listinfo/haskell-art
[Rohan Drape] Re: [Fwd: Re: [haskell-art] Re: Creating .wav or .aiff with SuperCollider/HSC3]
drat, different client same problem, sorry... --- Begin Message --- Henning Thielemann <[EMAIL PROTECTED]> writes: >> what gives that error? hosc or hsc3 or scsynth? > > scsynth ok, i'd guess that restriction could be trivially lifted for nrt but it is not usually an issue. of course, in this case the size was probably off by 2^31 or so... >> try unreversed encode_i32 (osc tends to use sized integers, >> this is the case also for bundle sizes) > > Is the difference between u32 and i32, unsigned vs. signed? yes, a typo in my message, replace sized with signed. > Good to know. perhaps... actually nrt in scsynth is very nice, what are ordinarily asynchronous operations become synchronous (eg. b_alloc and friends). rt designs generally 'degrade' well to nrt use, the other direction tends to be a disaster area. --- End Message --- ___ haskell-art mailing list [email protected] http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [Fwd: Re: [haskell-art] Re: Creating .wav or .aiff with SuperCollider/HSC3]
On Tue, 24 Jul 2007, Rohan Drape wrote: > followed wrong reply link, forwarding to list... > > Original Message > Subject: Re: [haskell-art] Re: Creating .wav or .aiff with > SuperCollider/HSC3 > From:"Rohan Drape" <[EMAIL PROTECTED]> > Date:Tue, July 24, 2007 9:52 am > To: "Henning Thielemann" <[EMAIL PROTECTED]> > -- > > On Tue, July 24, 2007 5:35 am, Henning Thielemann wrote: > > I have used the TCP transport data type and derived a File data type from > > it. However I got the error that the OSC message is longer than 8192 > > what gives that error? hosc or hsc3 or scsynth? scsynth > > let b = encodeOSC msg > > n = fromIntegral (B.length b) > > in B.hPut fd (B.append (B.reverse (encode_u32 n)) b) > > > > Now it seems that the times are not interpreted properly: > > try unreversed encode_i32 (osc tends to use sized integers, > this is the case also for bundle sizes) Is the difference between u32 and i32, unsigned vs. signed? > > Maybe this is still an issue of byte ordering. Server-Architecture.rtf > > states that values must be in network byte order. What is 'network byte > > order' in the case of files? > > network order = big endian. there are a few simple score functions at: > > http://slavepianos.org/rd/sw/sw-76/Rhs/Score.hs > > i've not used these recently though! Good to know. ___ haskell-art mailing list [email protected] http://lists.lurk.org/mailman/listinfo/haskell-art
[Fwd: Re: [haskell-art] Re: Creating .wav or .aiff with SuperCollider/HSC3]
followed wrong reply link, forwarding to list... Original Message Subject: Re: [haskell-art] Re: Creating .wav or .aiff with SuperCollider/HSC3 From:"Rohan Drape" <[EMAIL PROTECTED]> Date:Tue, July 24, 2007 9:52 am To: "Henning Thielemann" <[EMAIL PROTECTED]> -- On Tue, July 24, 2007 5:35 am, Henning Thielemann wrote: > I have used the TCP transport data type and derived a File data type from > it. However I got the error that the OSC message is longer than 8192 what gives that error? hosc or hsc3 or scsynth? > bytes. Thus I reversed the byte order in the length encoding: i doubt that was a good idea! > > let b = encodeOSC msg > n = fromIntegral (B.length b) > in B.hPut fd (B.append (B.reverse (encode_u32 n)) b) > > Now it seems that the times are not interpreted properly: try unreversed encode_i32 (osc tends to use sized integers, this is the case also for bundle sizes) > Maybe this is still an issue of byte ordering. Server-Architecture.rtf > states that values must be in network byte order. What is 'network byte > order' in the case of files? network order = big endian. there are a few simple score functions at: http://slavepianos.org/rd/sw/sw-76/Rhs/Score.hs i've not used these recently though! rd ___ haskell-art mailing list [email protected] http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Re: Creating .wav or .aiff with SuperCollider/HSC3
On Fri, 13 Jul 2007, Rohan Drape wrote: > On Thu, July 12, 2007 7:36 pm, Henning Thielemann wrote: > > > > On Wed, 11 Jul 2007, Henning Thielemann wrote: > > > >> I want to write the SuperCollider output into a file. > >> Server-Architecture.rtf tells me that I must use the -N option. However > >> I > >> need a file of OSC messages. Shall I replace all 'send' actions by > >> commands that write the messages to a file? Has someone already done > >> this? > > > > Maybe it's just another type to implement for the OSC.Transport class, > > which writes to files rather than the network. I'll try that. > > Yes, SC3 NRT files are just length prefixed sequences of OSC bundles, > see SC3 documentation for details. NRT works as expected, though recall > to have a null event to end the score (ie. processing ends at last bundle > timestamp). Timestamps are zero indexed. I have used the TCP transport data type and derived a File data type from it. However I got the error that the OSC message is longer than 8192 bytes. Thus I reversed the byte order in the length encoding: let b = encodeOSC msg n = fromIntegral (B.length b) in B.hPut fd (B.append (B.reverse (encode_u32 n)) b) Now it seems that the times are not interpreted properly: $ scsynth -D 0 -o 2 -N glissando.osc _ glissando.aiff 44100 AIFF int16 Using Altivec: no *** ERROR: open directory failed 'synthdefs' start time 0.501933 nextOSCPacket 1.10536e+07 *** Exception: waitForProcess: interrupted (Interrupted system call) Maybe this is still an issue of byte ordering. Server-Architecture.rtf states that values must be in network byte order. What is 'network byte order' in the case of files? ___ haskell-art mailing list [email protected] http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Re: Creating .wav or .aiff with SuperCollider/HSC3
On Fri, 13 Jul 2007, Rohan Drape wrote: > On Thu, July 12, 2007 7:36 pm, Henning Thielemann wrote: > > > > On Wed, 11 Jul 2007, Henning Thielemann wrote: > > > >> I want to write the SuperCollider output into a file. > >> Server-Architecture.rtf tells me that I must use the -N option. However > >> I > >> need a file of OSC messages. Shall I replace all 'send' actions by > >> commands that write the messages to a file? Has someone already done > >> this? > > > > Maybe it's just another type to implement for the OSC.Transport class, > > which writes to files rather than the network. I'll try that. It does also answer your question, what other types of Transport may exist. I think the type class approach is very clean here. > Yes, SC3 NRT files are just length prefixed sequences of OSC bundles, > see SC3 documentation for details. NRT works as expected, though recall > to have a null event to end the score (ie. processing ends at last bundle > timestamp). Timestamps are zero indexed. Good to know. > There is also recordBuf to stream audio to disk in RT. Ah, you have added this recently. ___ haskell-art mailing list [email protected] http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Re: Creating .wav or .aiff with SuperCollider/HSC3
On Thu, July 12, 2007 7:36 pm, Henning Thielemann wrote: > > On Wed, 11 Jul 2007, Henning Thielemann wrote: > >> I want to write the SuperCollider output into a file. >> Server-Architecture.rtf tells me that I must use the -N option. However >> I >> need a file of OSC messages. Shall I replace all 'send' actions by >> commands that write the messages to a file? Has someone already done >> this? > > Maybe it's just another type to implement for the OSC.Transport class, > which writes to files rather than the network. I'll try that. Yes, SC3 NRT files are just length prefixed sequences of OSC bundles, see SC3 documentation for details. NRT works as expected, though recall to have a null event to end the score (ie. processing ends at last bundle timestamp). Timestamps are zero indexed. There is also recordBuf to stream audio to disk in RT. Regards, Rohan ___ haskell-art mailing list [email protected] http://lists.lurk.org/mailman/listinfo/haskell-art
