electro-music.com   Dedicated to experimental electro-acoustic
and electronic music
 
    Front Page  |  Radio
 |  Media  |  Forum  |  Wiki  |  Links
Forum with support of Syndicator RSS
 FAQFAQ   CalendarCalendar   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   LinksLinks
 RegisterRegister   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in  Chat RoomChat Room 
 Forum index » Instruments and Equipment » Kyma
A few Kyma questions
Post new topic   Reply to topic
Page 1 of 2 [46 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
Goto page: 1, 2 Next
Author Message
DrJustice



Joined: Sep 13, 2004
Posts: 2114
Location: Morokulien
Audio files: 4

PostPosted: Thu May 07, 2009 9:09 am    Post subject: A few Kyma questions Reply with quote  Mark this post and the followings unread

Here's a few Kyma questions :

1. Is it a per sample iterated or a block iterated system?
2. How does it handle feedback (also relates to the previous question)?
3. Can somebdy post an example of how Capytalk is used?
4. The snippets of DSP code or DSP expressions that are mentioned, how does it look, how is it done? Is it the same thing as Capytalk? Can you make your own modules with it?
5. Can the wiring in the GUI be routed graphically as you want (like in a schematic drawing package)?

TIA!

DJ
--
Back to top
View user's profile Send private message Visit poster's website
seraph
Editor
Editor


Joined: Jun 21, 2003
Posts: 12398
Location: Firenze, Italy
Audio files: 33
G2 patch files: 2

PostPosted: Thu May 07, 2009 1:02 pm    Post subject: Reply with quote  Mark this post and the followings unread

TIA stands for Temperature Indicating Alarm, right Question

Rolling Eyes

_________________
homepage - blog - forum - youtube

Quote:
Don't die with your music still in you - Wayne Dyer
Back to top
View user's profile Send private message Visit poster's website
DrJustice



Joined: Sep 13, 2004
Posts: 2114
Location: Morokulien
Audio files: 4

PostPosted: Thu May 07, 2009 1:10 pm    Post subject: Reply with quote  Mark this post and the followings unread

Could it be Talking In Acronyms?

DJ
--
Back to top
View user's profile Send private message Visit poster's website
seraph
Editor
Editor


Joined: Jun 21, 2003
Posts: 12398
Location: Firenze, Italy
Audio files: 33
G2 patch files: 2

PostPosted: Thu May 07, 2009 1:23 pm    Post subject: Reply with quote  Mark this post and the followings unread

If you are The Intellectual Activist we could meet at Tucson International Airport. That Is Alright, make sure to carry The Internet Adapter with you and Thanks In Advance Exclamation Cool
_________________
homepage - blog - forum - youtube

Quote:
Don't die with your music still in you - Wayne Dyer
Back to top
View user's profile Send private message Visit poster's website
jksuperstar



Joined: Aug 20, 2004
Posts: 2503
Location: Denver
Audio files: 1
G2 patch files: 18

PostPosted: Thu May 07, 2009 7:20 pm    Post subject: Reply with quote  Mark this post and the followings unread

As far as I can tell, it's per sample iterated. The GUI just shows general flow between modules, and the rest is similar to programming (tossing variables around to communicate between modules)
Back to top
View user's profile Send private message Visit poster's website
BobTheDog



Joined: Feb 28, 2005
Posts: 4044
Location: England
Audio files: 32
G2 patch files: 15

PostPosted: Thu May 07, 2009 10:49 pm    Post subject: Re: A few Kyma questions Reply with quote  Mark this post and the followings unread

DrJustice wrote:
Here's a few Kyma questions :

1. Is it a per sample iterated or a block iterated system?
2. How does it handle feedback (also relates to the previous question)?
3. Can somebdy post an example of how Capytalk is used?
4. The snippets of DSP code or DSP expressions that are mentioned, how does it look, how is it done? Is it the same thing as Capytalk? Can you make your own modules with it?
5. Can the wiring in the GUI be routed graphically as you want (like in a schematic drawing package)?

TIA!

DJ
--


Well I am a bit of a beginner so this may all be wrong but here we go, also I will post these questions up on the Kyma forum to get some experts involved:

1. Not sure.

2. Also not quite sure yet, memory writing and reading could be used and maybe eventStreams.

3. There are some examples here: http://electro-music.com/forum/post-243058.html#243058

4. Currently you cannot write DSP code. From my current understanding CapyTalk can be used to affect parameters in existing DSP code and SmallTalk can be used to set up parameters and sounds. An SDK for writing DSP code is currently being worked on.

5. No. You can encapsulate sounds into a higher level sound and then choose public parameters. This tidys things up.

Cheers

Andy
Back to top
View user's profile Send private message
DrJustice



Joined: Sep 13, 2004
Posts: 2114
Location: Morokulien
Audio files: 4

PostPosted: Fri May 08, 2009 3:07 am    Post subject: Reply with quote  Mark this post and the followings unread

Thanks for the replies guys!

I had a look at the EQ example - very helpful and interesting!

On 5. I really meant the actual wires themselves, but it's useful to know that you can do encapsulation. Does that mean you can group any set of connected modules and use it as a 'macro', exposing the inputs and outputs you want? Does this extend to true hierarchial design (macros within macros)?

I note that in the Help window shown, the description of NbrPartials hints at a time divided evaluation of the envelopes. Presumably this is a principle that is used in other modules as well?

For the first time we non-Kyma owner have a chance to get a look-in - that's electro-music.com for you Very Happy

DJ
--
Back to top
View user's profile Send private message Visit poster's website
BobTheDog



Joined: Feb 28, 2005
Posts: 4044
Location: England
Audio files: 32
G2 patch files: 15

PostPosted: Fri May 08, 2009 4:23 am    Post subject: Reply with quote  Mark this post and the followings unread

DrJustice wrote:

On 5. I really meant the actual wires themselves, but it's useful to know that you can do encapsulation. Does that mean you can group any set of connected modules and use it as a 'macro', exposing the inputs and outputs you want? Does this extend to true hierarchial design (macros within macros)?


Yep I understood and meant meant No you cannot muck about with the wires.

Yep true hierarchal design, fantastic eh!


DrJustice wrote:

I note that in the Help window shown, the description of NbrPartials hints at a time divided evaluation of the envelopes. Presumably this is a principle that is used in other modules as well?


Seems to be used in the Spectrum modules. I haven't had much time to look at all the modules yet, still working my way through the manual which i must admit is great fun.


Also I have had a look at feedback and you seem to be able to read a sample that is being written without even a sample delay.

Although the stuff I have looked at uses a TimeOffset module to delay the read by a single sample, why I am not sure yet, maybe reading a sample being written may not always give the correct result.

I posted your first two questions on the Kyma forum so hopefully someone will get back on them.

Cheers

Andy
Back to top
View user's profile Send private message
BobTheDog



Joined: Feb 28, 2005
Posts: 4044
Location: England
Audio files: 32
G2 patch files: 15

PostPosted: Fri May 08, 2009 7:53 am    Post subject: Reply with quote  Mark this post and the followings unread

Got an answer:

>>>1. Is it a per sample iterated or a block iterated system?
Per sample (i.e., the entire signal flow graph is evaluated once per sample)

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

Write to memory at the "origin" and read from that memory at the feedback "destination".



I have asked about the need for a one sample delay when reading.
Back to top
View user's profile Send private message
DrJustice



Joined: Sep 13, 2004
Posts: 2114
Location: Morokulien
Audio files: 4

PostPosted: Fri May 08, 2009 8:55 am    Post subject: Reply with quote  Mark this post and the followings unread

Thanks for taking the trouble Andy!

That's excellent, just as such systems ought to be IMO. I assume that the write before read scheme still has the one sample 'transport' delay that occurs naturally through any one module. Looking forward to the answer on that last one re. use of one sample delays.

One more Q if you don't mind: can the timeline be synced as a slave to a MIDI sequencer (my guess is yes...)?

Sorry for going on and on... I'm very interested in these details....

DJ
--
Back to top
View user's profile Send private message Visit poster's website
BobTheDog



Joined: Feb 28, 2005
Posts: 4044
Location: England
Audio files: 32
G2 patch files: 15

PostPosted: Fri May 08, 2009 9:25 am    Post subject: Reply with quote  Mark this post and the followings unread

No Problem.

Just had a quick look, you can get at midi clock using the TimingClock variable

There is an example using a WaitUntil module to start timeline playback based on a midi key down event. But it looks like a WaitUntill module can be based around any event.

You can position the timeline to markers using MIDI program changes.

There are probably loads of ways to control the timeline but I have little understanding of it as I have been concentrating on Sound creation.

One thing I do know is that you cannot have a separate play point for each track on the timeline it is global.

Cheers

Andy
Back to top
View user's profile Send private message
mrbill



Joined: May 08, 2009
Posts: 8
Location: USA

PostPosted: Fri May 08, 2009 10:50 pm    Post subject: Kyma opinions
Subject description: a users thoughts on Kyma
Reply with quote  Mark this post and the followings unread

I'm new to this forum, but thought I should chime in on this. I've been a Kyma user for ten years. I have a Capybara 360 with three expansion cards - not quite Pacarana power, but pretty good. I must say I have a love-hate relationship with it.

First of all, there is no "ultimate" software/hardware. Everything has its strengths and weaknesses. Kyma is very good for some things, and incredibly frustrating for others.

I am a reasonably good programmer, but I find the syntax for Small/CapyTalk to be incredibly arcane and confusing. I do as little as possible with it.

As for hierarchy - there is essentially none. While it is true that you can create your own "prototypes", they are difficult to make, impossible to edit, and aren't subroutines in the usual sense. Everything in Kyma is a copy, nothing is referenced. If you instantiate an object ten times, you have to change all ten when you want to edit it. This is incredibly frustrating to me.

As for wiring in the GUI - Kyma restricts how you can connect objects, so you have cannot instantiate objects arbitrarily. This takes a lot of getting used to (compared to something like MAX, for example.) One possible advantage of this is that every program you can draw will compile - it may not do what you intended, but it will compile.

Objects in the GUI and in the VCS (the control interface) have minds of their own and will not always stay where you put them. This is especially a problem with large and complicated programs. You can move objects around on the screen to improve readability, but they will not be where you put them the next time you open the program.

From the user interface standpoint, the VCS is also problematic. The collection of widgets is limited and the graphics look like something from the 1980s. The VCS is linked to the last object in the signal flow, so if you change that object, you will lose any customization you put into the VCS.

I don't mean to sound totally negative, Kyma certainly has its strengths. But issues like these are impossible to know unless you actually use the system for a while, and some of them could be deal breakers to some users.

I have learned my way around over the years, and with Kyma I find that sometimes something very complicated sounding can be easy to implement, and sometimes the simplest thing can take hours or days to figure out.

I think Kyma is well suited for non-realtime sound generation, where you create raw audio material that can be edited in a conventional DAW environment . That said, I did just use mine for a live show in which I had to compile and load four consecutive programs and used Timelines with interactive controls from a pair of WiiMotes. (I must admit that I used quite a lot of profanity directed at Kyma while I was developing these programs!)

When I bought into Kyma, computers were slower, and dedicated hardware made sense. Over ten years, computers got faster, but my hardware didn't change. Now with the Pacarana, SSC has improved the hardware at last, but computers will still continue to get faster. If I were shopping today, I would take a good look at MAX/MSP/Jitter. It is cheaper, the programming environment is much simpler and user friendly, and the user interface is highly customizable. Plus it handles MIDI, which Kyma doesn't do well, and video, which Kyma doesn't do at all.
Back to top
View user's profile Send private message
BobTheDog



Joined: Feb 28, 2005
Posts: 4044
Location: England
Audio files: 32
G2 patch files: 15

PostPosted: Fri May 08, 2009 11:23 pm    Post subject: Reply with quote  Mark this post and the followings unread

welcome to the forum Bill.

Nice to have someone in the know here.

I am not sure why you say it has no hierarchy, it seems it has to me.

Even without using the prototypes I can create a sound out of a selection of other sounds. I can then use this encapsulated sound as a macro to insert into other sounds or add to the prototypes bar.

I was talking about the macros within macros idea as a hierarchy, the macros are expanded when you add them to another macro but I don't see this removes the idea of a hierarchy from the original question from DJ.

Maybe we are both using hierarchy in different ways?


I have not had the problem with VCS controls being different when loaded yet, that doesn't sound too good!


Interesting point about MAX/MSP/Jitter, I find Kyma much more intuitive than MAX/MSP I must admit. They are very different beasts though.


Also what problems do you have with MIDI in kyma?

Cheers
Andy
Back to top
View user's profile Send private message
BobTheDog



Joined: Feb 28, 2005
Posts: 4044
Location: England
Audio files: 32
G2 patch files: 15

PostPosted: Fri May 08, 2009 11:27 pm    Post subject: Reply with quote  Mark this post and the followings unread

This I thought was a good comparison (post 4)

http://www.gearslutz.com/board/electronic-music-instruments-electronic-music-production/343085-kyma-compared-max-msp-nord-modular.html
Back to top
View user's profile Send private message
mrbill



Joined: May 08, 2009
Posts: 8
Location: USA

PostPosted: Sat May 09, 2009 7:01 am    Post subject: more Kyma comments
Subject description: a comparison with MAX
Reply with quote  Mark this post and the followings unread

You are right, the gearslutz.com article is a very good comparison. I would agree with it completely.

I have been a MAX user since 1988, and a "casual" MSP user for about ten years. Since I own Kyma, it is my go-to solution for most sound design issues, so I haven't done any complex sound manipulation with MSP. I have created some very useful sound playback and realtime control systems with MSP. These would have been pointless to attempt in Kyma.

As I pointed out in my first post, everything has its strengths and weaknesses. MAX/MSP is better suited for complicated control problems than Kyma. The Kyma/WiiMote performance I mentioned was successful and I made everything work, but I will use MAX/MSP for the next version because of the frustrations I had with Kyma.

Kyma does provide higher level functions encapsulated into prototypes than MAX does. This allows a user to start making sounds right away, despite the overall complexity of the system, so even though there is a very steep learning curve, there can also be a bit of instant gratification to keep you going. The Kyma community is small, but the forum allows direct access to the two people that created it, and they will often solve your problem for you. Their customer service and dedication to their product is unparalleled.

With MAX you must build things from the ground up, so you really do have to know what you're doing. This means the learning curve is steep and there can be initial frustration. The "help" program that opens for each object is very handy, editable, and often I copy and paste parts of it to use as a starting point in a program. The MAX community is huge and very open - you can get help from other users, often in the form of patches and third-party objects that will solve your problems. It is taught in almost every university electronic music program, so there are a lot of users out there doing a lot of sophisticated things with it.

MAX's user interface is far and away better than Kyma, both in terms of the graphical environment that you can create, and in the programming environment itself. This is a big issue for me - I've been using Macintosh since 1986 and am a true believer in the importance of the user interface. MAX/MSP is full of attractive GUI widgets that can be customized into very usable and intuitive interfaces.

In terms of the programming environment, MAX is easier to debug and do quick experiments. You can graphically arrange things any way you want, you can hide objects and wires, color-code and group objects, I could go on, but this post is long enough.
Back to top
View user's profile Send private message
mrbill



Joined: May 08, 2009
Posts: 8
Location: USA

PostPosted: Sat May 09, 2009 7:20 am    Post subject: Kyma opinions
Subject description: Kyma and hierarchy
Reply with quote  Mark this post and the followings unread

Here is what I mean by hierarchy: subroutines and encapsulation.

In programming, it is useful to create a block of code that can be written once and used in multiple places - a subroutine. The code is referenced by each instantiation, and if you edit the code, all instances of it will change (because they point to it.) You can not do this in Kyma.

In organization, when you get a lot of components together that relate to one function, or just get too cluttered, it is useful to "put them in a box" so all you see are the inputs and outputs. You group and encapsulate multiple things into one thing. This "box" can be placed inside another "box" and so on, allowing you to have a clear structure. This makes it easier to understand the signal flow, edit, change, re-use, etc. You can not do this in Kyma.

It is possible to do what Kyma calls "create a class" out of one of your programs, but this is an unwieldy and complicated process, and is it impossible to edit the contents without starting over. Once you have tried this a few times, you will not do it again.

I see this as the single biggest drawback to the Kyma environment, and one where MAX/MSP truly excels.
Back to top
View user's profile Send private message
mrbill



Joined: May 08, 2009
Posts: 8
Location: USA

PostPosted: Sat May 09, 2009 7:31 am    Post subject: Kyma opinions
Subject description: Kyma and MIDI
Reply with quote  Mark this post and the followings unread

Kyma uses MIDI, of course, but it is primarily a receiver. MIDI generation within Kyma is somewhat arcane. There are only a handful of objects that generate MIDI messages, and they sometimes require very specific knowledge. You will need a copy of the MIDI spec to work out the correct code for CC#10 on channel 6, for example.

MAX was created for writing MIDI programs, so the comparison to Kyma is unfair. But MAX offers many MIDI-specific objects that allow you to easily do anything you want with MIDI data.
Back to top
View user's profile Send private message
BobTheDog



Joined: Feb 28, 2005
Posts: 4044
Location: England
Audio files: 32
G2 patch files: 15

PostPosted: Sat May 09, 2009 9:01 am    Post subject: Re: Kyma opinions
Subject description: Kyma and hierarchy
Reply with quote  Mark this post and the followings unread

Hi Bill,


mrbill wrote:

Here is what I mean by hierarchy: subroutines and encapsulation.


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.

mrbill wrote:

In programming, it is useful to create a block of code that can be written once and used in multiple places - a subroutine. The code is referenced by each instantiation, and if you edit the code, all instances of it will change (because they point to it.) You can not do this in Kyma.


I understand this, adding a sound to an existing sound always creates a copy of the sound being added.

This has its advantages as well as its disadvantages. The main advantage is that I can change my source sound without affecting any of the sounds that were created using the original.

In most large software systems this would be the way things are done with multiple branches of source being maintained. Modules would be moved between branches to control impact of change. For example the main software system I work has around 15 separate branches at the moment. It is a manual process to move changes between branches after impact analysis has been done.

This idea works for Kyma as well, if I change a sound and would like that sound to be used in another sound that used the original I can manually replace it. What seems to be missing in Kyma is the idea of finding sounds that the original sound was used and replacing it with a new version, this I must admit would be useful, along with integration to a source control system such as the evil that is SVN.



mrbill wrote:

In organization, when you get a lot of components together that relate to one function, or just get too cluttered, it is useful to "put them in a box" so all you see are the inputs and outputs. You group and encapsulate multiple things into one thing. This "box" can be placed inside another "box" and so on, allowing you to have a clear structure. This makes it easier to understand the signal flow, edit, change, re-use, etc. You can not do this in Kyma.




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

Also could you not use "lifted" sounds and parameter variables to give this idea of abstraction and Construct these sounds algorithmically, or have I got the wrong end of the stick about these?


mrbill wrote:

It is possible to do what Kyma calls "create a class" out of one of your programs, but this is an unwieldy and complicated process, and is it impossible to edit the contents without starting over. Once you have tried this a few times, you will not do it again.

I see this as the single biggest drawback to the Kyma environment, and one where MAX/MSP truly excels.



This was what I was talking about to DJ, I must admit I haven't fully read that part of the manual yet, isn't this what SymbolicSound do do create the prototype sound objects for Kyma?


Cheers

Andy
Back to top
View user's profile Send private message
bphenix



Joined: Apr 20, 2009
Posts: 17
Location: austin, tx

PostPosted: Sat May 09, 2009 9:56 am    Post subject: Reply with quote  Mark this post and the followings unread

I've made a number of class objects in the past and it is both very useful and also a fair bit tedious to make. I really like to make them because it allows you to create things like fully contained effects or modules like oscillators and save of complexity within the signal graph. There are some tricks that make editing an existing one a bit easier but it certainly could use some updating. If the class editor had drag and drop why to lay out the parameters and then it would be mostly just fine for me.

I can see many of MrBill's points, though, I personally don't really find it a problem. I found Kyma the '3rd path' that I was looking as MAX/MSP, csound, supercollider, among others just were not doing it for me.

One thing mentioned would be nice, though I never really thought about it before: sound aliases. Rather than copies being made within the signal graph, you could create aliases that reference a source sound. You can sorta do this by making one sound route into multiple objects but it does have limits and it doesn't work across different complied programs. It would likely mean creating a new class of objects that are the 'library'. I'd hate to modify the source and find it having unexpected cascading effects across my library of sounds.
Back to top
View user's profile Send private message AIM Address
bphenix



Joined: Apr 20, 2009
Posts: 17
Location: austin, tx

PostPosted: Sat May 09, 2009 10:54 am    Post subject: Reply with quote  Mark this post and the followings unread

back to original questions.


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).

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.

My personal favorite is to create wavetable 'feedback' systems. Since you can read / write to just about anywhere you can do a lot of fun things with creating feedback loops to points you wouldn't normally consider.


3. Can somebdy post an example of how Capytalk is used?

Here is a simple example. Say you want to module a parameter with a triangle shape. You could easily attach an LFO or you could simple type:

1 repeatingTriangle: 1 s

This starts of the triangle at compilation lets it run for a duration of 1 second and then repeats. The 1 at the beginning is the 'trigger'.

Now only trigger when you press down a key:

!KeyDown repeatingTriangle: 1 s

This basically says, every time the key is pressed trigger the repeating triangle again. Now say you want to control the modulation amount in real time:

(!KeyDown repeatingTriangle: 1 s) * !LfoMod

This would generate a controller to the VCS (the real time controller interface) that would let you control how much of the repeating triangle is applied to that parameter where you inserted it.

Tempo sync:

(!KeyDown repeatingTriangle: 120 bpm s) * !LfoMod

Now with the bpm to be variable and controlled by a fadar on the VCS:

(!KeyDown repeatingTriangle: !LFObpm bpm s) * !LfoMod


Of course, you can get a lot more fancy but that is a basic, and common, example.

You could also easily map in a midi cc value into an expression to control or sync with external midi generators. I did that with the !KeyDown, but you can do a full range of others as well. There are so many ways to do that this post could go on for a few more thousand words.


4. The snippets of DSP code or DSP expressions that are mentioned, how does it look, how is it done? Is it the same thing as Capytalk? Can you make your own modules with it?

Out aside things like the timeline (which is a sort of sequencer for sound objects), there is a couple of levels of sound objects.

The one that you work in the most are called 'sounds'. This gets a bit confusing in terms of communicating with others, so I often call them sound objects to define them as 'contained'. However, all objects (whether here or in other systems) are nothing more than DSP code abstracted.

All sound objects are encapsulated code with only a few parameters exposed for you to control. These parameters can be controlled in real time or fixed at the time compiling.

For example, if you look at this:
http://www.symbolicsound.com/brochure%20X/small-DAG%20normal.jpg

The top part is the signal flow. The bottom part is the parameters only for the delay sound object. If you select another sound object you'll be present with those parameters.

Now, you can create new sound objects by collecting them into a new 'class' which is just a way to collapse many objects into one single one. At the time of doing so, you choose which parameters are exposed and which are hidden now.

Additionally. you can write all new machine level DSP which are called 'microsounds'. This is even a lower level and can be used to write a new DSP filter, for example. You don't have to know anything about this layer though unless you want.

There is also the ability to script if you like that sort of thing.

Back to Capytalk. Capytalk is used within sounds to create control expressions. 90% of the time it is simple little stuff like I wrote up there. It can be much more extensive though. There is a library of expressions for common tasks to help you along that can be dragged and dropped into your sound.


5. Can the wiring in the GUI be routed graphically as you want (like in a schematic drawing package)?

You don't drop and object in and then wire them up. I think a video would be easier to understand, but you basically drag objects from the library into a place within the signal flow and it adds it there. You can also copy and paste from one part of the flow to another. Once it is in the signal flow you can drag the sound into another. You don't drag wires around though (like in a modular or MAX/MSP), you drag objects into the input area of another sound. The input area could be a defined audio input or a hot parameter field.
Back to top
View user's profile Send private message AIM Address
BobTheDog



Joined: Feb 28, 2005
Posts: 4044
Location: England
Audio files: 32
G2 patch files: 15

PostPosted: Sat May 09, 2009 11:35 am    Post subject: Reply with quote  Mark this post and the followings unread

bphenix wrote:

Additionally. you can write all new machine level DSP which are called 'microsounds'. This is even a lower level and can be used to write a new DSP filter, for example. You don't have to know anything about this layer though unless you want.


Hi,

This is currently not possible with the Paca and Pacarana. SymbolicSound are working on a new SDK to enable this to work but it is going to take some time apparently.

Cheers

Andy
Back to top
View user's profile Send private message
BobTheDog



Joined: Feb 28, 2005
Posts: 4044
Location: England
Audio files: 32
G2 patch files: 15

PostPosted: Sat May 09, 2009 1:00 pm    Post subject: Reply with quote  Mark this post and the followings unread

DrJustice wrote:

One more Q if you don't mind: can the timeline be synced as a slave to a MIDI sequencer (my guess is yes...)?


I have a bit of an update on this.

MIDI Clock can be used in your sounds but not to start and stop the timeline or to seep to a position on the timeline. You can use it to affect the BPM of the timeline.

The Timeline position can only be directly controlled by MIDI Timecode which is a bit of a bugger if you use Ableton Live.

You can use the WaitUntil module to wait for an event so I am sure it would be possible to get the timeline to start using a Midi clock start message.

I am looking into it more.

Cheers

Andy
Back to top
View user's profile Send private message
mrbill



Joined: May 08, 2009
Posts: 8
Location: USA

PostPosted: Sat May 09, 2009 2:31 pm    Post subject: Re: Kyma opinions
Subject description: Kyma and hierarchy
Reply with quote  Mark this post and the followings unread

BobTheDog wrote:

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.)
Back to top
View user's profile Send private message
BobTheDog



Joined: Feb 28, 2005
Posts: 4044
Location: England
Audio files: 32
G2 patch files: 15

PostPosted: Sat May 09, 2009 10:06 pm    Post subject: Reply with quote  Mark this post and the followings unread

Hi Bill,

I see you point now, one of the first things that confused me about Kyma was that I was trying to double click sound icons to open another window to see the contents. It took me quite a while to realise that this was not the way it worked. So as you say the actual sound editor itself is not hierarchical.

I must admit I thought you could expand user defined encapsulating classes though, is this not possible then?

Thanks

Andy
Back to top
View user's profile Send private message
mrbill



Joined: May 08, 2009
Posts: 8
Location: USA

PostPosted: Sun May 10, 2009 6:59 am    Post subject: Reply with quote  Mark this post and the followings unread

BobTheDog wrote:
Hi Bill,
I must admit I thought you could expand user defined encapsulating classes though, is this not possible then?


You can't "push into" them to make edits. If you "expand" an object, you just flatten it into the current level of the program.

A better methodology is to keep source code which you can modify, then re-encapsulate it into a new object (class) represented by an icon.

You must take care though, because you can easily create multiple versions of the same object (if you modify and re-encapsulate it several times) that could all have the same name. Also, you must manually replace every instantiation of the old version with the new one, everywhere it occurs.

From a programming point of view, I see this as a major limitation - and I'm not really a software kinda guy.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic
Page 1 of 2 [46 Posts]
View unread posts
View new posts in the last week
Goto page: 1, 2 Next
Mark the topic unread :: View previous topic :: View next topic
 Forum index » Instruments and Equipment » Kyma
Jump to:  

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


Forum with support of Syndicator RSS
Powered by phpBB © 2001, 2005 phpBB Group
Copyright © 2003 through 2009 by electro-music.com - Conditions Of Use