Kyma/Capy/Paca used to be a bit an enigma. Now I'm starting to get a feel for how it works. I appreciate that both pros and cons are surfacing here. Hopefully this thread is useful to others as well. Please keep the discussion going among you users!

bphenix wrote:

2. How does it handle feedback (also relates to the previous question)?

You write to a buffer and then read it out. As the entire system is evaluated once per sample that sorta informs your minimum buffer length, though in practice it tends to be around 10 samples at minimum (at least on the capy320, not sure about the pacarana as mine is backordered).

Does this mean that you have to explicitly insert a feedback buffer in your patch? How does this fit in with the way objects place themselves in the graph, when you want a feedback path from anywhere to anywhere else? There's got to be a wire looping back into the signal flow somewhere(?)

bphenix wrote:

There are lots of ways to achieve feedback systems. One of the drawbacks of the Capy320 is that many feedback systems were confined to a single DSP chip (in many, though not all cases). I am not sure if that is still true but even if so, the new chips are so much more powerful, it won't likely be an issue.

Having a patch span several DSPs is not trivial from a developers view. I can see that feedback, or even straight signal flow, across DSPs is a problem.

On other points of interest, I note that the hierarchal design facilities are not implemented as a 'real' hierarchal editor and that there are some complexities involved.

Even though I don't expect that many users do it, the ability to go all the way down and write DSP code is good (TBI in Pacarana, I understand). I assume that this is the same facility that Symbolic Sound use themselves - that would make sense. Big plus for openness there.

MIDI Clock and Song Position Pointer would've been nice to have for the timeline. I'm not sure how widespread MIDI Time Code is.

So far, I'd say there is a bit more "Research Institution Flavour" than "MIDI Project Studio Flavour" to it. That's not necessarily a bad thing in itself, just a bit different than what most of us are used to I guess.

Does this mean that you have to explicitly insert a feedback buffer in your patch? How does this fit in with the way objects place themselves in the graph, when you want a feedback path from anywhere to anywhere else? There's got to be a wire looping back into the signal flow somewhere(?)

There are 2 primary ways to do feedback.

There are many places you can read a file from and pretty much all of them you can connect them to a memory writer buffer (including many which may not be labelled as 'read from memorywriter'). Writing to a buffer is as simple as inserting an sound object into your flow and giving it a name. It can be continuous or triggered. You can define the size as well if it is passive and lets the sound continue on the signal flow or it mutes the audio at that point.

It does not visually wire together to the place(s) that are reading from that buffer. I sometimes name the objects in the signal flow if it is useful.

The second way is to use a pair of objects called Feedback Input and Feedback Output. These are slightly different than the above method in that they actually create a virtual input and ouput within the signal flow. It also means that you can span across more than one DSP card (usually) since these are treated as IO rather than buffers. An aside, Kyma allows you to insert IO from physical (or in the capy's case core audio -- paca support is forthcoming) sources at any point in the signal flow.

You can pair the Feedback IO together via the same name. You can write once, read multiple and have multiple independent sets. It is a continuous stream unlike the memorywriter referenced above.

Again the signal flow does not wire the 2 sound objects together, you just see the point at which it writes and then reads by the object type (the icon image) + the arbitrary name you assign to the object.

Well I am not too sure that you need subroutines and encapsulation for a hierarchy myself. I was talking about the fact that a sound which can be represented by one icon can contain many other linked sounds, with each of these sounds containing many other sounds and so on. So you have a tree of sound graphs.

You can't push down into a prototype to see how it works or change it. So while it may contain other linked sounds, you can't know what they are or affect them in any way. The prototypes (icons) are more like atoms.

BobTheDog wrote:

I must admit I see sounds as this "box", they seem to encapsulate things to me.

Wait until you have created a program with 15-20 prototypes and you will understand why it would be nice to have a way to encapsulate functions and build an hierarchical structure. Kyma graphical programming (i.e.- with prototypes in the "Sound" editor) is flat, not hierarchical.

(You will also understand why it is frustrating to not be able to organize objects on the screen they way you want to see them.)

Hi Bill,

I can see your point on these issues, things could be better and already some parts of Kyma are beginning to annoy me.

But from another viewpoint it is very easy with kyma to start making things that sound pretty good, maybe after a time of using it I will start getting annoyed by the inadequacies that you mention and forget the magic of it.

To be quite honest for me I have managed to get more useful audio from Kyma in a week that I have from MAX/MSP in a couple of years, and I think the reason for this is that I can grab a load of library sounds and connect them together in a serendipitous way, I like this idea of things.

On other points of interest, I note that the hierarchal design facilities are not implemented as a 'real' hierarchal editor and that there are some complexities involved.

Yep I now understand that when you add a sound into the graph of another sound it is a copy of that sound pasted in.

So one step up from a G2 and one down from say Max or Reaktor.

Even so Kyma is designed to easily allow you to hear what one sound would sound like with another sound as its input, this is built into the browser, you can choose a source sound and see what it is like played through another sound. In any sound you create you can set a single point in the structure where another sound could be inserted by the browser by auditioning.

Also in your sound structure it is easy to replace one sound with another, to place a sound between one sound and another in series and to place a sound between two sounds in parallel.

DrJustice wrote:

Even though I don't expect that many users do it, the ability to go all the way down and write DSP code is good (TBI in Pacarana, I understand). I assume that this is the same facility that Symbolic Sound use themselves - that would make sense. Big plus for openness there.

I am looking forward to this, it came as a bit of a surprise to me that this was not available already. They seem to be changing from a 56K assembler approach to a C approach for this, I have asked if 56K will be supported but have not had an answer yet.

DrJustice wrote:

MIDI Clock and Song Position Pointer would've been nice to have for the timeline. I'm not sure how widespread MIDI Time Code is.

This is an absolute pain, I am hoping there is a way around this, still looking into it.....

DrJustice wrote:

So far, I'd say there is a bit more "Research Institution Flavour" than "MIDI Project Studio Flavour" to it. That's not necessarily a bad thing in itself, just a bit different than what most of us are used to I guess.

I heard mention of a TI DSP chip, which would imply the 1GHz C6xxx series? In which case, the 56k machine code wouldn't help;) The Symbolic Sound site mentioned somewhere that the paca had 2 processors, while the pacarana had 4. There's no Freescale DSPs that offer this much power in 4 chips. Nor support that much ram!

But those TI ones are very nice, 1GHz, triple core choices. I wonder if the new Kyma hardware uses triple core, or floating point, etc, etc...

To be quite honest for me I have managed to get more useful audio from Kyma in a week that I have from MAX/MSP in a couple of years, and I think the reason for this is that I can grab a load of library sounds and connect them together in a serendipitous way, I like this idea of things.

Kyma does have a much higher "instant gratification" factor than MAX does. This is good in that it will keep you involved and pursuing your goals with it.

I continue to use mine after 10 years, despite how much it frustrates me sometimes.

Might be useful ... at the time I was at the university I didn't get too much of that Smalltalk stuff ... it was not very helpful of course that we were dropped into meta compilation immediately _________________Jan
(yawning shifts perceived pitch, making things more interesting)

SSC has always been open about their architecture and provided access to the underpinnings so they wouldn't hide behind an NDA unless they actually were bound to. Given that there has been a few delays due to batches of chips coming in that were not up to spec, it points to a very new chip, perhaps not one widely or publicly available yet.

The prior chip make and model was publicly posted on the website and I am sure this will be as so as they are able to. Given only a small fraction of users develop their own DSP, it was a reasonable trade off to leave out for the initial release. SCC made it clear it was something they are working on so it will be there in time.

1) The whole algo is calculated once every sample but each chip is one sample behind the other. Hence modules on the left will be scheduled on the first chip in the chain.

2) There are two ways to handle feed back first memory reader and writer pair but kyma will schedule this such that both are on the same chip. If you put to much processing between them it won't schedule. This gives you a delay of minimum one sample. The other method of feedback is a feedback in out pair. This sends the signal through to the last chip and passes it back to the first. This has a minimum delay of the number of chips you have in your system in samples, but you have no restriction on where they are.

3) Capytalk doesn't work at sample rate it is more for control signals but it's still fast. It can be placed anywhere in the hot param fields inside the modules. The modules (Interconnected) do work at sample and you have a large selection of arithmetic and logic modules as well as more complex ones that can be interconnected to allow you to make algos that work fully at sample rate.

4) You can make your own modules by encapsulating circuits of other modules which could then be encapsulated to make more. There is an SDK for DSP assembly programing but this does not come with the system. You have to ask SSC for this. At this stage it is only for the Capybara and I believe that there are only six of us that are currently using it. I think most find they don't need it or would rather someone else deal with that stuff. Here you make raw DSP modules which sit in with the rest of kyma.

5) You can wire what you want in the schematic but you can not leave it in a state of non working. i.e. you can insert modules on the wires between modules to get the schematic you want but you cannot have non connected modules sitting on the screen waiting to be connected. The GUI is normally referring to the VCS (Virtual Control Surface) which is another window that displays all the controls you have defined in capy talk. Note defining is as simple as !FRED typed in a hot parameter field and you have a control called FRED on the VCS.

Sorry if I've gone over what has already been covered but I hope it helps.

It kept asking me to verify the hidden code and it seemed to come up with an average of two zeros or "O"s , so there was a 4 to 1 chance of getting it wrong, but Murphy's law made sure that the odds were worse than that.

I kept running out of attempts and had to wait for the following day.

I eventually got round it by deleting some cookies to get more attempts in the same day attempts.

By this time most of the points had been covered but I decided to post it anyway.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum

Please support our site. If you click through and buy from our affiliate partners, we earn a small commission.