Anyone interested in working with me on porting PortAudio (http://portaudio.com/) to Squeak? I've never built a primitive before although I've gotten the Linux 3.8 VM to build using VMMaker (whew.) So, if you have experience in this area, that would be an added bonus!
I want to start on Linux first using v19 preferably with the JACK (http://jackit.sourceforge.net/) interface,. But ALSA (http://alsa-project.org/) would be fine for now. Linux primarily because of the free C tools - I have no C tools for Windows or Mac. But, if someone would like to help and start with Windows, I could get tools. (I don't have a MAC at my disposal right now. But, if you'd like to start on MAC, I could potentially get one.)
Please let me know online or off if you're interested. I think it would make a great addition to the usefulness of Squeak for audio and video.
thanks,
brad
Use an external plugin, Luke. You can generate it, compile it, load it to test, unload, rewrite a bit, generate it , compile it and round and round without even having to quit squeak.
tim
tim Rowledge wrote:
Use an external plugin, Luke. You can generate it, compile it, load it to test, unload, rewrite a bit, generate it , compile it and round and round without even having to quit squeak.
tim
Thank you, oh wise Obi-Wan. :-) That's what I usually do... chew a little bit at a time...
On 1-Nov-05, at 1:53 PM, Brad Fuller wrote:
tim Rowledge wrote:
Use an external plugin, Luke. You can generate it, compile it, load it to test, unload, rewrite a bit, generate it , compile it and round and round without even having to quit squeak.
tim
Thank you, oh wise Obi-Wan. :-) That's what I usually do... chew a little bit at a time...
Wise padawan. Make sure it is nice and clean, use a subclass of SmartSyntaxInterpreterPlugin if possible and little by little you can duck-nibble the problem to death.
tim
I'll note you can choose to either make:
A lightweight plugin that interfaces to a platform-agnostic api that requires you to use lots of platform specific C code.
A heavyweight class(es) that manages data and passes data only to a plugin which makes the DLL API call, no pre/post C code wrapping api call. or a plugin that abuses self cCode: inSmalltalk: and makes the api calls required and has no external C code, except for say a DLL library of some sort.
Or of course use FFI.
In some respects exposing the RAW DLL API in a plugin then having a heavyweight class drive it is best because any changes to logic can mostly be done in smalltalk, otherwise with a platform agnostic API you get to post and mange change via external C code and publish plugins forever...
So for example:
primitiveMPEG3AudioSamples: fileHandle stream: aNumber | file result |
"long mpeg3_audio_samples(mpeg3_t *file, int stream)" self var: #file declareC: 'mpeg3_t * file'. self primitive: 'primitiveMPEG3AudioSamples' parameters: #(Oop SmallInteger).
file := self mpeg3tValueOf: fileHandle. file = nil ifTrue: [^0]. aNumber < 0 ifTrue: [interpreterProxy success: false. ^nil]. aNumber >= (self cCode: 'mpeg3_total_astreams(file)') ifTrue: [ interpreterProxy success: false. ^0. ].
self cCode: 'result = mpeg3_audio_samples(file,aNumber)'. ^result asOop: Float
I could have made the check for file nil, and the check for stream part of the smalltalk code that interfaces to the plugin so that I would only have primitiveMPEG3AudioSamples: fileHandle stream: aNumber | result |
"long mpeg3_audio_samples(mpeg3_t *file, int stream)" self var: #file declareC: 'mpeg3_t * file'. self primitive: 'primitiveMPEG3AudioSamples' parameters: #(Oop SmallInteger). self cCode: 'result = mpeg3_audio_samples(file,aNumber)'. ^result asOop: Float
Note we return the samples as a Float to avoid the issue with small versus large integers. I guess today we could return a 32bit Integer, but I believe those methods was added later when we were working on the large file indexing support.
On 1-Nov-05, at 2:01 PM, tim Rowledge wrote:
Wise padawan. Make sure it is nice and clean, use a subclass of SmartSyntaxInterpreterPlugin if possible and little by little you can duck-nibble the problem to death.
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
John M McIntosh wrote:
I'll note you can choose to either make:
A lightweight plugin that interfaces to a platform-agnostic api that requires you to use lots of platform specific C code.
A heavyweight class(es) that manages data and passes data only to a plugin which makes the DLL API call, no pre/post C code wrapping api call. or a plugin that abuses self cCode: inSmalltalk: and makes the api calls required and has no external C code, except for say a DLL library of some sort.
Thanks for your input, John. Don't you think the former (lightweight) would be more beneficial (in the long run) for cross platform support? Then again, any update to PortAudio might mean more C programming in the primitive? (oopss.. you agree.. I just re-read below!)
What do you suggest?
Or of course use FFI.
Don't you think FFI would not be a good choice for my goal to be easily cross platform? I don't know, I don't have any real-world experience with primitives nor FFI except for reading the doc on the swiki
In some respects exposing the RAW DLL API in a plugin then having a heavyweight class drive it is best because any changes to logic can mostly be done in smalltalk, otherwise with a platform agnostic API you get to post and mange change via external C code and publish plugins forever...
So for example:
primitiveMPEG3AudioSamples: fileHandle stream: aNumber | file result |
"long mpeg3_audio_samples(mpeg3_t *file, int stream)" self var: #file declareC: 'mpeg3_t * file'. self primitive: 'primitiveMPEG3AudioSamples' parameters: #(Oop SmallInteger). file := self mpeg3tValueOf: fileHandle. file = nil ifTrue: [^0]. aNumber < 0 ifTrue: [interpreterProxy success: false. ^nil]. aNumber >= (self cCode: 'mpeg3_total_astreams(file)') ifTrue: [ interpreterProxy success: false. ^0. ]. self cCode: 'result = mpeg3_audio_samples(file,aNumber)'. ^result asOop: Float
I could have made the check for file nil, and the check for stream part of the smalltalk code that interfaces to the plugin so that I would only have primitiveMPEG3AudioSamples: fileHandle stream: aNumber | result |
"long mpeg3_audio_samples(mpeg3_t *file, int stream)" self var: #file declareC: 'mpeg3_t * file'. self primitive: 'primitiveMPEG3AudioSamples' parameters: #(Oop SmallInteger). self cCode: 'result = mpeg3_audio_samples(file,aNumber)'. ^result asOop: Float
Note we return the samples as a Float to avoid the issue with small versus large integers. I guess today we could return a 32bit Integer, but I believe those methods was added later when we were working on the large file indexing support.
On 2-Nov-05, at 5:32 PM, Brad Fuller wrote:
John M McIntosh wrote:
I'll note you can choose to either make:
A lightweight plugin that interfaces to a platform-agnostic api that requires you to use lots of platform specific C code.
A heavyweight class(es) that manages data and passes data only to a plugin which makes the DLL API call, no pre/post C code wrapping api call. or a plugin that abuses self cCode: inSmalltalk: and makes the api calls required and has no external C code, except for say a DLL library of some sort.
Thanks for your input, John. Don't you think the former (lightweight) would be more beneficial (in the long run) for cross platform support? Then again, any update to PortAudio might mean more C programming in the primitive? (oopss.. you agree.. I just re-read below!)
What do you suggest?
In the past, the number of people willing to fix and update primitive based plugs is small, the number to update smalltalk code is large. People also realize that the knowledge to build a plugin is high, although a team member of the Sophie project is attempting to address this issue. Both flavours then have different issues when promoting change into the base VM/Image.
Or of course use FFI.
Don't you think FFI would not be a good choice for my goal to be easily cross platform? I don't know, I don't have any real-world experience with primitives nor FFI except for reading the doc on the swiki
Well lots of things in croquet are done via FFI. The issue is performance, the setup for FFI calls is large as compared to plugin call. If you go with FFI expect to spend some time learning how to stuff things in/out of C structures via smalltalk code, where as a lightweight plugin can do the conversion to/from objects with less hassle.
Mind of course with FFI changes are smalltalk code (and perhaps a third party dll) , versus a plugin with smalltalk, c code, a binary, and the third party dll.
Maybe someone else can comment? I've really only done both heavy and lightweight plugins and fixed the FFI code from time to time.
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
Hey, this sounds interesting! We've built loads of PortAudio interfaces, including for VisualWorks. It's all pretty easy, but you have to manage the timing of the audio call-backs and Smalltalk semaphores carefully to avoid dropping buffers. There's cross- platform VW wrapper code (using the DLLCC Smalltalk-to-C API) in the Siren7 release (http://www.create.ucsb.edu/Siren/Siren7.2.tgz).
stp
-- Stephen Travis Pope -- http://create.ucsb.edu/~stp Dept. of Music and Grad. Program in Media Arts and Technology University of California, Santa Barbara
Begin forwarded message:
From: Brad Fuller brad@sonaural.com Date: November 1, 2005 10:43:33 AM PST To: Squeak List squeak-dev@lists.squeakfoundation.org, squeakaudio@create.ucsb.edu Subject: [SqueakAudio] PortAudio Port Help Request
Anyone interested in working with me on porting PortAudio (http:// portaudio.com/) to Squeak? I've never built a primitive before although I've gotten the Linux 3.8 VM to build using VMMaker (whew.) So, if you have experience in this area, that would be an added bonus!
I want to start on Linux first using v19 preferably with the JACK (http://jackit.sourceforge.net/) interface,. But ALSA (http://alsa- project.org/) would be fine for now. Linux primarily because of the free C tools - I have no C tools for Windows or Mac. But, if someone would like to help and start with Windows, I could get tools. (I don't have a MAC at my disposal right now. But, if you'd like to start on MAC, I could potentially get one.)
Please let me know online or off if you're interested. I think it would make a great addition to the usefulness of Squeak for audio and video.
thanks,
brad
Stephen Travis Pope wrote:
Hey, this sounds interesting! We've built loads of PortAudio interfaces, including for VisualWorks. It's all pretty easy, but you have to manage the timing of the audio call-backs and Smalltalk semaphores carefully to avoid dropping buffers. There's cross- platform VW wrapper code (using the DLLCC Smalltalk-to-C API) in the Siren7 release (http://www.create.ucsb.edu/Siren/Siren7.2.tgz).
stp
Thanks Stephen! I know nothing about WV wrapper method. How (dis)similar is it to Squeak primitives or FFI? Any more wisdom of your PortAudio<->VW journey is most welcome.
What version of PortAudio have you linked to?
-- Stephen Travis Pope -- http://create.ucsb.edu/~stp Dept. of Music and Grad. Program in Media Arts and Technology University of California, Santa Barbara
Begin forwarded message:
From: Brad Fuller brad@sonaural.com Date: November 1, 2005 10:43:33 AM PST To: Squeak List squeak-dev@lists.squeakfoundation.org, squeakaudio@create.ucsb.edu Subject: [SqueakAudio] PortAudio Port Help Request
Anyone interested in working with me on porting PortAudio (http:// portaudio.com/) to Squeak? I've never built a primitive before although I've gotten the Linux 3.8 VM to build using VMMaker (whew.) So, if you have experience in this area, that would be an added bonus!
I want to start on Linux first using v19 preferably with the JACK (http://jackit.sourceforge.net/) interface,. But ALSA (http://alsa- project.org/) would be fine for now. Linux primarily because of the free C tools - I have no C tools for Windows or Mac. But, if someone would like to help and start with Windows, I could get tools. (I don't have a MAC at my disposal right now. But, if you'd like to start on MAC, I could potentially get one.)
Please let me know online or off if you're interested. I think it would make a great addition to the usefulness of Squeak for audio and video.
thanks,
brad
squeak-dev@lists.squeakfoundation.org