posted 23 January 2010 14:16            

First worked analysing provided scripts as examples (existing prototypes as detailed within the Kyma X revealed book)

I however had difficulties at understanding some of the syntax used. Some of it doesn't come from nor exists in the provided index & reference tables at the end of the book, nor could be found in some smalltalk reference manual found on the web through miscelanneous links searching this topic

This especially concerns the CSound Score to MIDI Script prototype :
Some variable called 'file' is later described as a 'Preferences' object with some sort of aruments such as locateFiledNamed, OfType, locateMessage etc. Where that sort of Preferences class comes from ? Where these values such as locateMessage and others come from ?

Later a local variable called 'f' received the result from the expression "file asFilename textFileStream". Then I asked myself where that 'textFileStream' comes from ? ..

Found also quite puzzling that the paramArray was given the result from the f 'nextParameters'...so I wonder where that 'nextParameters' keyword comes from ? It seems that 'textFileStream' and 'nextParameters ' keywords share some common field, yet unknown.

Etc

SSC : may it be possible to get further information about where those particular keyword and syntax comes / were inspired from ? Is there any special or particular existing Reference manual or document that could be specified here as a link in order to stay tuned on a same 'wavelength' ? Many thanks in advance for your help.

posted 23 January 2010 15:07            

People often ask us to recommend a generic reference on the Smalltalk language and, although we're happy to suggest references, we always add that many of the messages you can use in Kyma exist only in Kyma, and you will not find anything about them in standard references.

It might help to think of these messages as function calls. In C, for example, you can define a set of functions and put them into a library. Someone else could link to that library and make calls to those functions in their own code, almost as if those function calls were part of the C language.

posted 24 January 2010 03:47            

That particular case with Csound is litteraly described (partially) in text pages of the book, but not 'synthetically' in form of a table as proposed with the other references at the end of the document. Eventually, a 'man' for these would had been great.

This may or may not have strong interestest, however this became like a hide and seek game when I tried to fully master those pieces of code because there was no way to perfectly understand the syntax & sense of using these keywords. And still there is not.

posted 04 February 2010 12:39            

If one wants to create the script aside (before injecting it to Kyma script prototype window), can this be done using an interpreter such as VisualWorks ? (sure, the '!' prefix used for kyma controls will be not used in that case to avoid what will be detected as syntax bugs)

posted 04 February 2010 13:43            

One thing you could use is Smalltalk blocks. You can define a block to take any number of arguments and assign it to a variable. Then you can send the message "value" or "value:" to that object to evaluate the block. For example, if you select and evaluate this code, the result will be 5:

code:

---

| simpleProc |
simpleProc := [:a :b | a + b].
simpleProc value: 2 value: 3.

---

See page 219 in _Kyma X Revealed_ for additional examples.

"If one wants to create the script aside (before injecting it to Kyma script prototype window), "

One way to test parts of the code would be to create a text file in Kyma and paste your code into it. You can select a portion of code and use ctrl+y to evaluate it.

posted 14 February 2010 04:48            

Here is an example :

| simpleProc var1 var2 |
simpleProc := [:a | a + 0,5 ].

posted 15 February 2010 03:48            

I may eventually expand the idea up to defining a virtual keyboard (a 2 octaves range) at the bottom of the wacom pannel so it may then be used to generate midi events, and also exploid the advantage of glide capabilities and the wacom pen inclinaison (somewhat similar to the Continuum Fingerboard).
All that script should mainly consist in processing 'where' the pen hit the board, (it involves rescaling and translating X and Y positions and comparing them against some "defined" static ranges)

The main idea behind this can be used also such that the wacom could be divided into tiny parallel 'bars' such that some resynthesized sound spectra could be controlled and reshaped with the wacom pen in real time while replaying the sound (say something like a real time formant filter). Something similar to what was possible some time ago when using the CMI instruments...

posted 15 February 2010 11:06            

Re the two areas of the pad. One thing to remember is that the system remembers the X,Y position last touched when you remove the pen from the pad. If you have two areas you will need extra positional memories so that nothing will change in one area when the pen is doing things in the other area. I think two pairs of "track and hold" could help out here so that it will be kept in hold mode while the pen is in the other area and in track mode when the pen is in the current area.

As far as the keyboard is concerned the upper part (where the black notes live) could be done with using "truncated" as in that area each semitone covers the same width, but the lower area (where you see only white notes) would need an array with elements 0,2,4,5,7,9,11,12 etc as the white notes are not equidistant pitch wise.

Here "Sample and hold" could store the difference between the quantized (truncated) position and the actual position at the point of first press. This way you can guarantee an exact semitone border on impact but then freely and smoothly ride the pen after that.

This doesn't tell you how to do it but may give some pointers.

Small talk is good for setting things up but Capy talk has the realtime power.

Hope it helps

posted 15 February 2010 12:50            

As for the keyboard, as I stated in my previous post, it's also a matter of rescaling and comparing wacom pen location against 'predefined zones'; Using comparison statements (conditionnal blocks), this would then treshold midi notes. But let's put that keyboard idea aside for the time being, as this is only an 'expansion' of the idea in first place.

Since smalltalk involves looping instructions (despite it was mentionned above the scripts are evaluated only once _ correct me if I'm mistaken _) , then the enginuity sits there since loops can be infinite ones, it means that the pen position can be permanently tracked and processed. Script I wish to make would involve capytalk expressions anyway.

May this post be the occasion to ask definitely one thing for sure : are smalltalk scripts evaluated only once or can they be 'reactive' to some new events ("concurrent statements") ? If smalltalk script involve loops, such as infinite ones, does it lock the overall system ? or does it make it possible to get things processed all the way ?
As SSC suggested, "concurrency" can be obtained from capytalk expressions... so as soon as there is capytalk within smalltalk, then can this be a way to access the concurrency behavior within the script ? Can capytalk be just a matter of having one !parameter sitting in the middle of a conditionnal block or a loop etc..?

posted 15 February 2010 13:23            

CapyTalk expressions have an implied infinite loop around them. I think they are the way to implement your pen-tracker. Pete makes a valid point about also using a trackAndHold.

We could start by dividing the tablet into quadrants:

Another key is that in CapyTalk, "less than" is lt: and "greater than" is gt:
And to translate a logic AND to CapyTalk, use a multiply '*'
To do a logic OR, use a plus "+"

So to test whether the Pen is in the lower right quadrant, you could use:

(!PenX gt: 0.5) * (!PenY lt: 0.5)

This could be the gate that you use on a trackAndHold:, for example

((!PenX gt: 0.5) * (!PenY lt: 0.5)) trackAndHold: (!PenX - 0.5 * 2)

would offset the !PenX and double it so its scale becomes 0 to 1 when you move it in that quadrant.

posted 15 February 2010 14:19            

quote:

---

May this post be the occasion to ask definitely one thing for sure : are smalltalk scripts evaluated only once or can they be 'reactive' to some new events ("concurrent statements") ? If smalltalk script involve loops, such as infinite ones, does it lock the overall system ?

---

posted 20 February 2010 10:02            

quote:

---

Originally posted by Sylvain KEPLER:
Thank you SSC, my goal consists in dividing the Wacom board in smaller individual rectangular zones so that some areas can be dedicated for controlling 2 distinct parameters on X an Y axis.

---

Hi Sylvain,

Sorry that I saw this conversation late, after you already solved the problem, but I put a patch like this on the tweaky awhile ago. It's called "FourWacomsInOne.kym." You might be interested to compare the solutions. I'd be curious about other functionality you might have in your solution.

It's pretty fun to play with. At the time I never used it much because the more complicated variations would always max out my capybara by the time I added an interesting sound for it to control, but now that I try it with the Pacarana I see that it barely registers on the DSP Usage!

best,
Phil

posted 21 February 2010 16:01            

quote:

---

Originally posted by Sylvain KEPLER:
= I 'm not sure this is so much processor consumming; While using my own work yesterday, I noticed that only one DSP ,among the 14 DSP I have there in, was mainly used, so still plenty of DSP usage available aside for some other processing.

---

Yeah, I think that the high CPU usage on the Capy was because I was creating global controllers for all the normal pen controls times four (!BottomLeftPenX, !TopLeftPenX, !TopRightPenX, etc.) and then also using them to control useful parameters within a sound. There's also a few extra features in the more complicated/cpu-intensive sounds, like momentary takeover when the !PenButton1 is held down, with values that smoothly return to the previous values when the button is released, etc.