MIDI is not a concern because MIDI is slooooooooowwwwwwww far slower than pharo. Audio processing now thats tricky at 44khz per second that a lot of calculations and general speaking you would not want to use smalltalk for that part. Even C has to be heavily optimised and you need to 100% know what you doing. When things come down to language speed, there is a huge "IT DEPENDS" , you know the one that is carried as a huge labeled panel by small airplanes in the sky. So pharo offers you actually loads of options on this one. 1) FFI , now with this option you can call compiled libs from pharo, nativeboost is the modern solution but there are older FFIs too that pharo has carried from squeak. This way you can use existing C libs that do the job. 2) C compiling, now in this case you may want to compile your own C code, again you can use FFI or you can compile it as a VM plugin. Its up to you. I think this is how Etoys in Squeak implements the FM synthesizer. 3) Assembly , with nativeboost now its allowed to inline assembly code, this option has the advantages that everything is kept at smalltalk side, of course you still code in assembly and compilation is automatic so you dont need to worry about that. But assembly is platform specific so you will need create different code for different platforms.  Of course machine code is blazzing fast. 4) Sockets, now this is not an obvious solutions but is what I am considering for my project Ephestos, There are like tons of midi and audio tools that can be operated by sockets. The biggest example is supercollider, supercollider has a server that does all the audio and mid processing, generally you communicate with its server via sclang which is language that copies smalltalk features heavily. However there is also the option of communication via sockets and to be precise using the osc protocol which is actually a replacement to MIDI far more powerful and far more faster. This option is also a great one because supercollider is a beast , with tons of features, a big community and a tool that has well proven its worth for over a decade now. Its far more powerful than any MIDI or AUDIO app you have used and unlike other tools is not only realtime but live coding orientated like pharo. So my goal is to bring eventualy supercollider to pharo users. But its not a big priority of mine right now. So those are more or less your options. As you can see its not only doable , but doable in many diffirent ways, every one with its advantage and disadvantage , so pick your poison and carry on ;) Please not that this ways are implemented in any other language , apart from nativeboost of course. About GC , well in that case when you call a C lib or do machine code via nativeboost assembler you bypass GC unless you use smalltalk objects, AFAIK VM stops any action and executes your C / Assembly code and resumes after execution. However there will be an overhead to compile the code and to call the code. That means generally that you will need to profile and see how much code needs to be ported to assembly/C to reduce these overheads.  Its all about having a good idea how your code works.  My sockets solution also wont have you worried about GC since it throws all heavy computation to the supercollider server , that means way less things to worry about. Apparently you can have your cake and eat it too ;) On Friday, 18 October 2013, 10:23, Paul Davidowitz <pdavidow@fastmail.fm> wrote: Can Pharo be used for 'realtime' applications such as music midi or metronome? Isn't garbage collection a concern? (But I once read that Tektronix used Smalltalk in their oscilloscopes.) Thanks, -Paul