Is it possible to utilize third-party Smalltalk libraries/packages?

Question

I'm not well informed yet of the possible differences between Smalltalk systems / dialects, but since seeing Squeak mentioned here in another question, I figured this might be worth asking...

Since finding a Prolog package for Squeak a few months ago, I thought it might be very interesting to use it in Kyma. I downloaded the newest version of both Squeak and the package, and managed to get it working in Squeak with not too much effort.

I assumed that in a more dense package such as this, the chances that it uses some syntax or language construct unique to Squeak and not recognized in Kyma would be higher than a simpler library offering more common functionality.

However, I'm really just guessing about this, so I figure it's worth asking about here:

(1) If Kyma can import external code libraries/packages, how is it done?

(2) No matter the answer to (1), how different is Kyma Smalltalk to Squeak, if at all?

 

Thanks,

    Thom

Comments

This is an excellent question!

From my perspective, most of kyma is centred around the idea of processing numbers, particularly numbers in the range of 0 to 1, or -1 to 1 and doing that in real-time. This makes perfect sense for doing DSP with sound.

I think of music as being largely symbolic rather than numeric. Musical ideas can be represented by data structures that are more like a language with tree or graph like structures. The AI languages like prolog and lisp are great at creating and manipulating structures like this. Lists are particularly useful data structures for symbolic manipulation so python isn't too shabby at this kind of thing either.

While capytalk can access arrays I haven't yet seen it do "lists". I don't think it can extend arrays or iterate over them. This makes sense if you're trying to guarantee DSP execution within a real-time window, but isn't helpful if you're trying to do symbolic reasoning.

It is possible to write a "tool" in kyma and this lets you write in smalltalk (as opposed to capytalk) so presumably we can do lists but we can't import any libraries. To take my favourite example of python, there are huge numbers of libraries that let you do machine learning, natural language processing, work with graph data structures etc etc. You don't really want to code all that from scratch in kyma.

So for what I would call musical reasoning, the approach I've been taking is to code that part in another language, like python or prolog etc. And then we have to use OSC as the API into kyma. So far my experiments with OSC have only worked reliably when I pass numbers in the range of 0 to 1. Maybe that's ok because I don't know what kyma would do with a symbol should it receive one. I have butted up against this issue a number of times.

I'm still trying to find a good architecture for this kind of thing. I'm resisting putting real-time scheduling in python. I think the proper place for that is kyma (or a DAW). The asynchronous symbolic reasoning would then be python and that would require a bi-directional link between python and kyma... I guess over OSC. Which means plugging in an ethernet cable between the paca and the pc.

It would be nice if there was an easier bi-directional API for calling out to other languages and getting results back - through the kyma pc application, for instance.

Would it be possible to write a tool to do that?

---

Hi Alan, thanks for sharing your perspective. It helps to hear about approaches and solutions other users have decided upon after traveling the same path. I could see using a tool to call into other processes using OSC, and also receiving results asynchronously via OSC as well as retrieving larger blocks of data through a shared file or files, if larger arrays are troublesome to pass over OSC. I haven't yet delved into this so I'm not sure yet if OSC alone will suffice yet or not.

"Musical ideas can be represented by data structures that are more like a language with tree or graph like structures."  HEAR HERE !  :-)

Answer 1

The best approach might be to run the Prolog package in Squeak and communicate with Kyma via OSC.  There's no direct way to import a code package and the class libraries would not be compatible.