Part 1: Maps and devices are conceptually the same thing
A device does three things. A device groups together some conceptually related endpoints aka signals. When the input signals to the device receive data, the device does something, or changes something about what it is doing. As a result of the things the device does, it sometimes updates its output signals.
A map does three things. A map connects together some conceptually related endpoints. When input signals to the map are updated, the map does something, or changes something about what it is doing. As a result of the things the map does, it sometimes updates its output signals.
Maps and devices are basically the same thing. They have inputs and outputs related to which they do some computation or transformation.
Part 2: Maps and devices in libmapper are different things.
Except for some important differences. Devices can be implemented in any language, and as such may access special resources such as sensors and transducers. Maps are always implemented in mapper script. Because all libmapper network participants can run a mapper script VM, this means maps can run anywhere on the network. However, maps cannot directly access special resources.
Part 3: Maps and devices in libmapper should be more like each other
If we added a way for maps to describe their endpoints (calls equivalent to mpr_sig_new in mapper script so that we can give map endpoints a name, range, unit, etc.), then it would be possible to implement devices in mapper script. This would be very very useful, and also super cool. It would be easy to extend existing devices with new signals in this way, where the new signals are derived from the existing ones. It would also be possible to define common devices like envelope generators, LFOs, sequencers, loopers, etc. purely in mapper script, and instantiate multiple copies of them, and so one. These mapper-script devices could run anywhere on the network (wherever it's most efficient probably?). It would also be easy to restore these devices between sessions; you would never need to worry about a script device being offline.
If we added a way for libmapper network participants to advertise capability to run scripts in languages other than mapper script, then it would be possible to implement things in these languages. For a concrete example, suppose we added a compile-time optional binding for faust. Any libmapper client running a version of the library compiled with this binding enabled would be able to run faust code. We could then write our maps in faust code, and indeed, we could also define devices in faust code. The faust code could run wherever it's most efficient to run it, and it would be trivial to restore these devices between sessions.
Wouldn't it be nice if your synth was as easy to restore as your maps?
Wouldn't it be nice if you could write maps in whatever language you already know and love instead of having to learn yet another language?
Part 4: Conclusion
So there are two proposals embedded here. One: allow devices to be defined and instantiated based on scripting languages such as mapper script. Two: allow compile-time-optional bindings to embed arbitrary 3rd party scripting languages into the libmapper ecosystem.
We have traditionally focused our binding efforts on binding libmapper to 3rd party ecosystems. The crux of my suggestion here is that we consider doing it the other way around. I think you'll agree that doing so offers some interesting possibilities. Faust, libpd, lua, javascript, glsl... in libmapper?! I think that would be rad.
TW