search

gogins / csound-extended

Extensions for Csound including algorithmic composition, Android app, and WebAssembly.
GNU Lesser General Public License v2.1
40 stars 1 forks source link

Rethink design of playpen thanks to the Clang opcodes for Csound #190

Closed gogins closed 2 years ago

gogins commented 2 years ago

Ideally all pieces run from a standard code editor, all code is contained in one Csound .csd file, and HTML5 is supported. On reflection, I think this would be better than GTK.

The basic principle, based on much contrary experience, is that all Csound integrations should be implemented and used as Csound plugin opcodes. Only this guarantees that every part of a piece can be written in a .csd file.

gogins commented 2 years ago

Always keeping in mind, this stuff already has far too many dependencies, and I have just added quite a few for the Clang opcodes.

gogins commented 2 years ago

Seems to me this can be done with the Chromium Embedded Framework and calling CefDoMessageLoopWork on a timer or in csoundPerformKsmps.

There would opcodes to interface with CEF. These require thought. A C++ interface could also be supported for the Clang opcodes.

But the WebKit browser might be a better choice because CEF involves multiple processes. This can probably be adapted: https://wiki.gnome.org/Projects/WebKitGtk/ProgrammingGuide/Tutorial.

Or better yet the https://github.com/WebKit/WebKit/tree/main/Tools/MiniBrowser. If I can get this up in Csound I can proceed.

gogins commented 2 years ago

Here are my design principles for the computer music playpen, in other words, for extending my toolkit for algorithmic composition and synthesis:

  1. Every extension must be internal to Csound. That is, every extension is a Csound plugin or a Csound include file, and every extension is created, initialized, and used in Csound orchestra code. If necessary, source code in other languages is embedded in the Csound orchestra code. Only in this way can all extensions be used with all other extensions: Csound itself is the binder, the middleware.
  2. It follows that all code for a piece will be compiled by Csound at run time without need for external tools.
  3. Every external dependency must be standard -- very widely used, cross-platform, not likely to go away, and well maintained.
  4. There will be no compromises as to computer power. This in turn implies using Csound code, C++, and HTML5 as the basic languages.

These principles follow from developing or contributing to many front ends for Csound that I have ended up not using. Only C++, Python, and HTML5 have I used much.

Similar tendencies can be observed e.g. in SuperCollider, ChuCK, Pure Data, etc.

gogins commented 2 years ago

Building WebKit from source did not work out of the box for me at all. The MiniBrowser did not build out of the box.

I will see how many files are involved in the MiniBrowser and try to build it against the system packages for WebKit. If I can, good, if not, I will try the simple example. Not so many files...

gogins commented 2 years ago

Gtkmm doesn't wrap WebKit, but see this; https://stackoverflow.com/questions/17039942/example-of-using-webkitgtk-with-gtkmm-3-0. Worked right out of the box.

gogins commented 2 years ago

I have completed a usable version of WebKit opcodes for Csound, that constitutes my rethought design for now. Moving on to compose some music this way. The takeway is this:

The general philosophy is now to push all software used to make music with Csound down into Csound itself, in the form of plugin opcodes. Everything is compiled at run time by Csound, by the embedded Clang JIT compiler, or by the embedded WebKit browser.

In this way, Csound itself is the only tool, or the top-level tool, used for composing.