Hi,
I have been playing around with writesf~, trying to save '.au' files (nextstep), and I'm getting weird results. I'm hoping someone else can verify this.
I have a Windows machine running PD 0.37.0. When I use writesf~ to save a file in 'au' format (using the -nextstep flag) the resulting file is malformed (I can't open it with any sound program). After a little inspection to the generated file it seems to me that the file is always big-indian encoded (it also seems that the -little/-big flags have no effect, the file is always the same). Also it seems that field 2 of the file header (data size) is filled with zeroes when, according to http://brandt.kurowski.net/projects/lsa/wiki/view.cgi?doc=588, it should be filled with ones.
I made a test patch (see attach) to reproduce these results .
I experimented re-arranging the file manually and it can be played afterwards...
Hope someone can shed some light on this.
Thanks, jc
Ps: I sent this message to the pd-dev list, but it seems that that list is kind of dead so I'm re-posting it here...
Jorge Cardoso <-> jorgecardoso@ieee.org
Centro de Investigação em Ciência e Tecnologia das Artes (CITAR) Univ. Católica - CRP -> Escola das Artes -> Dept. Som e Imagem Rua Diogo Botelho 1327 4169 - 005 Porto Portugal
"Whether you believe you can, or whether you believe you can't, you're absolutely right." - Henry Ford
Hi, I'm currently trying to use the 'comport' object to receive data from a microcontroller at a speed of 115200baud. However as soon as I send data, the GUI pretty much freezes - some number boxes still update, but all interactivity with GUI objects is lost.
Has anyone experienced this behaviour before ? Is the baudrate simply too high ? (I'm on a Athlon 1GHz/Win2000)
I know serial FIFOs are usually rather small, I think 16 bytes in this case, so that with 115200baud Windows is interrupted at 115200/(8*16) = 900Hz or about every millisecond. But can this have such a large impact on system responsiveness?
I also tried to change the polling interval with the 'pollintervall' message but it didn't seem to change much. Looking at comport's source code it seems to me that comport_tick() seems to reschedule itself always at 1ms intervals no matter what the value x->x_deltime is. Not sure though.
I thought of moving my data parsing code into an external object that reads from the COM port directly, but I fear it's a more general problem so I'd welcome your input.
Thanks, Sukandar
hi Jorge,
Jorge Cardoso wrote: ...
When I use writesf~ to save a file in 'au' format (using the -nextstep flag) the resulting file is malformed (I can't open it with any sound program). After a little inspection to the generated file it seems to me that the file is always big-indian encoded (it also seems that the -little/-big flags have no effect, the file is
indeed (except that I got them always little-endian, i.e. "dns.").
Looks like soundfiler_writeargparse() is broken: the `logic' of its .snd file forming part is to have machine-endian as default, unless for a -big or -little flags both picking a secondary default, which is little-endian.
The code has not been corrected, since probably nobody uses next/sun format anymore, while aiff and wav's endiannes is fixed.
Btw... Miller -- are not you going to use an external sound file library (libsndfile, whatever) eventually, are you? If not, would not you be willing to expose some of d_soudfile.c calls, would you?
k
...
Ps: I sent this message to the pd-dev list, but it seems that that list is kind of dead so I'm re-posting it here...
very much alive (asleep perhaps, intoxicated...)
-
Jorge Cardoso -
Krzysztof Czaja -
Sukandar Kartadinata