On and on feasibility of implementing Kyma natively?

DSP, Plugin and Host development discussion.
RELATED
PRODUCTS

Post

Good point about the Score.
Cecilia4 standalone was built on Csound but is now rewritten using a python dsp module (a sign of things to come?)
Cecilia5 is quite creative though, and can be routed on macs using the new Blackhole app.
F E E D
Y O U R
F L O W

Post

whyterabbyt wrote: Thu Oct 31, 2019 12:48 pm Its probably the best front-end for (non-plugin) CSound, but its all about the Score, not the Instrument.
It seems you are wrong. You can edit instruments in a textual form and even make GUIs for them.

http://write.flossmanuals.net/csound/blue/
https://blue.kunstmusik.com/manual/html ... ilder.html

Post

lobanov wrote: Mon Nov 04, 2019 11:01 pm
whyterabbyt wrote: Thu Oct 31, 2019 12:48 pm Its probably the best front-end for (non-plugin) CSound, but its all about the Score, not the Instrument.
It seems you are wrong. You can edit instruments in a textual form and even make GUIs for them.

http://write.flossmanuals.net/csound/blue/
https://blue.kunstmusik.com/manual/html ... ilder.html
It seems you've not understood what kind of front-end I was talking about. Reread my posts where I was specifically talking about a visual-programming style front-end for instrument design. That's my context. Editing instruments in a textual form, or making a GUI, doesnt come under that.
An idiot on Set Theory:
"In some cases there is an object called red that contains everything that is red. In much the same way a pot is a plate."

Post

Coming back to this thread after yet more experience about differences between native offerings and Kyma "market".

I'm quite confident that the closedness of the Kyma platform is limiting musicians, since not everyone can afford it. Yet if offers substantial "something", which is not elsewhere.

I have not traversed through the entire library, but to me it seems also that a lot of the Kyma stuff is not necessarily particularly "proprietary", but based on well-known methods from papers. Since e.g. there are only few ways to process FFTs, modal banks etc. Their novelity perhaps comes from the "ready modular blocks" approach from the musicians perspective. As well as some insight about "musicality", e.g. what blocks fit together.

Post

Michael L wrote: Thu Oct 31, 2019 12:07 pm Have you tried the Csound environment, blue?
https://blue.kunstmusik.com
I have known about this, but previously I have not had the computer science knowledge in order to dwelve into it. Nowadays I view that, yes it's possibly a good comparison to the Kyma.

But a "commonish" complaint about Csound from musician's has been that it feels too much like engineering, when musicians would want "ready to play" or "plug and play" kind of behavior. I also recognize this pitfall. When I'm making music, I don't want to think about coding, because its a separate effort. Rather, I want something that works and has known behavior. Therefore, IMO, the musical richness of these kinds of platforms is in "how well they allow connecting blocks together".

Another complaint is that it doesn't integrate well with conventional DAWs (but this is also a problem of Kyma). For which I believe Cabbage is trying to offer a solution. Cabbage is actually pretty nice framework in the sense that it exports to VST, yet if one wished to alter the configuration, then it exposes the script that implements it. Since it's possible to add extensions to Csound, then this is again a viable, but perhaps not fully explored "alternative Kyma" framework. Where this might fall short is speed.

For the speed issue there's FAUST (https://faust.grame.fr/), but FAUST lacks a bit the "ready playability" of Cabbage. It requires more configuration to get up to being used in DAW. And again it doesn't have the modules that Kyma has.
Last edited by soundmodel on Fri Sep 04, 2020 8:36 am, edited 8 times in total.

Post

Michael L wrote: Wed Sep 19, 2018 12:12 pm What Kyma functions are missing in the VST market?
This is (obviously) the first part of figuring out how to "nativize" the stuff available in Kyma. Again I'm not suggesting copyright breaches, but more like "open source adaptation".

I believe something that has long been unattainable in native has been high-quality additive synthesis. It has used to be that native software such as Camel Audio Alchemy limit to 600 partials, when I believe the Kyma does higher than this. High count of partials is required for "non-distorted" reconstruction after pitch- and time-stretch or other FFT modifications such as "spectral morph" or "spectral blur".

Post

The many plugins Puremagnetik has done with Cabbage (see his website) are a good example of 'plug & play' and he has some open source examples:
https://puremagnetik.com/blogs/news/fre ... n-sketches
I am only Cabbage-curious so cannot share real knowledge on this.

Another approach is to integrate plugins with a modular DAW that has sample editing, warping, DSP and devices like MuLab.
F E E D
Y O U R
F L O W

Post

Michael L wrote: Fri Sep 04, 2020 11:25 am Another approach is to integrate plugins with a modular DAW that has sample editing, warping, DSP and devices like MuLab.
This is not useful for the broad category of DAW musicians, who use VST. n-Track has Pure Data integration. Several other DAWs have some sort of patcher at least. But these are unideal for the goal of "reaching most musicians". See the problem with Kyma, Reaktor etc. is that theyre' closed platforms, which limits their usability. FAUST is much more general.

Post

soundmodel wrote: Fri Sep 04, 2020 11:59 am
Michael L wrote: Fri Sep 04, 2020 11:25 am Another approach is to integrate plugins with a modular DAW that has sample editing, warping, DSP and devices like MuLab.
This is not useful for the broad category of DAW musicians, who use VST.
You know that the 'plugins' he's talking about is the superset of 'VST' right? And no, not all DAW musicians do use VST, vastly more use.... plugins.
Including AAX plugins and AU plugins and LADSPA plugins.
n-Track has Pure Data integration. Several other DAWs have some sort of patcher at least. But these are unideal for the goal of "reaching most musicians".


So ? Any tool not being a guitar is non-ideal for reaching most musicians.
See the problem with Kyma, Reaktor etc. is that theyre' closed platforms, which limits their usability.


No it doesnt.
FAUST is much more general.
No it isnt.
An idiot on Set Theory:
"In some cases there is an object called red that contains everything that is red. In much the same way a pot is a plate."

Post

whyterabbyt wrote: Fri Sep 04, 2020 1:11 pm
soundmodel wrote: Fri Sep 04, 2020 11:59 amSee the problem with Kyma, Reaktor etc. is that theyre' closed platforms, which limits their usability.
No it doesnt.
soundmodel wrote: Fri Sep 04, 2020 11:59 amFAUST is much more general.
No it isnt.
Explain. Visual programming languages such as Reaktor have well-measurable "low productivity" and "expressivity problems" gaps compared to text-based languages with well-designed syntax. Depending on task of course, but in this "developing native Kyma"-case.

And to use them one has to own licenses to them.

Also, if the SDK is managed, then it disallows adding extensions. Want to bring some new feature to Reaktor, do you have to work at NI?

Post

soundmodel wrote: Sat Sep 05, 2020 8:16 am Explain.
1) Try asking politely instead of demanding.
2) Ive given exactly as much explanation as you did for your assertion.
An idiot on Set Theory:
"In some cases there is an object called red that contains everything that is red. In much the same way a pot is a plate."

Post

In 1967, the amazing composer James Tenney taught Fortran programming to fellow composers John Cage, Steve Reich, Nam June Paik and others at the home of two other composers in New York. Reich moved there after finishing his Masters at Mills College under Berio where he, among other things, formed bands with John Chowning (inventor of FM synthesis) and the future Grateful Dead bass (Lesh) and keyboard (Constanten) players. Nowadays Reich does mockups of his compositions with NNXT in Reason. That explains it all.
F E E D
Y O U R
F L O W

Post

Oh, great, now Im getting Fortran flashbacks. f**king hollerith descriptors.
An idiot on Set Theory:
"In some cases there is an object called red that contains everything that is red. In much the same way a pot is a plate."

Post

Kyma is written in Smalltalk (by Alan Kay for the Dynabook!) so it may have a lower risk to mental health, but I am not taking any chances....
F E E D
Y O U R
F L O W

Post

I'm refreshing this topic because I was reading my Kyma book again, and I somewhat think that the older Kymas are a bit old-school. The library in general feels fantastic, but the user interface is very 90s. And the box feels like a giant dongle.

I'd like to contribute to a native Kyma-like library, but not alone.

This could also allow promoting Smalltalk back to native programs as well.

https://medium.com/smalltalk-talk/why-a ... de31b6e3f4

I also still don't believe that any of the sound algorithms are proprietary, but at most personal modifications over well-known DSP techniques. The real power of Kyma is, IMO, not in these, but how it allows them to be utilized in a very high-level user interface. If one would give the library as a C++ library, then it'd not be as useful.

Again, I'm not suggesting copying it, but simply implementing something similar in usability.

Post Reply

Return to “DSP and Plugin Development”