posted 05 February 2009 10:05            

!Fader delay: 1 s

The only way I can think to do this now is to paste !Fader into a constant, put that behind an audio delay, and paste that where needed. But it would be nice to have an expression that could do it, and it would seem to be more efficient as well, since you would be delaying at control rate rather than audio rate.

But maybe it exists already and I've overlooked it?

posted 19 February 2009 10:23            

(I just mentioned this delay stuff in Taylor's post about looping as well.)

I posted a capytalk expression in the Wiki that delays triggers:

| DelayedTrigger |

DelayedTrigger := [ :condition :delay nduration ]
| reset trigger1 trigger2 |
reset := EventVariable new.
trigger1 := condition setReset: reset.
trigger2 := ((trigger1 ramp: delay s + 1 ms) eq: 1) setReset: reset.
(reset <+ ((trigger2 ramp: onduration s + 1 ms) eq: 1),
trigger2)
].

It does not however delay an arbitrary capytalk expression, which might take on a different value every ms. I think that without array assignments in capytalk (SSC: that would be such a nice feature!) it is very difficult to do. With arrays, you could easily write something that would delay an arbitrary capytalk expression by a given duration (using one array location for every ms of delay).

posted 26 February 2009 10:15            

A FunGen that outputs its wavetable for all of its OnDuration regardless if the trigger changes , and then reseting its trigger to 0 when its OnDuration is over.

I can't seem to find a way of doing this simple thing.

posted 26 February 2009 10:41            

code:

---

| DelayedTrigger |

DelayedTrigger := [ :condition :delay    nduration |
| reset trigger1 trigger2 |
reset := EventVariable new.
trigger1 := condition setReset: reset.
trigger2 := ((trigger1 ramp: delay s + 1 ms) eq: 1) setReset: reset.
(reset <+ ((trigger2 ramp: onduration s + 1 ms) eq: 1),
trigger2)
].

---

So does the expression !Trigger ramp: 1 s always complete the ramp up over the duration despite the !Trigger dropping to 0 or changing before the 1 second is up?

posted 02 March 2009 15:50            

The first two characters of the parameter onduration got replaced by a the smiley token (colon o). I copied it right out of working code, so unless I somehow botched something in the copy/paste operation, I think it should be usable.

To use it, you have to call DelayedTrigger, as in:

DelayedTrigger value: !KeyDown value: 2 s value: 1 s

This will result in a trigger that comes on 2 s after !KeyDown, and lasts for 1 s. The trigger happens regardless of what happens to !KeyDown after it makes the initial transition that sets the whole thing in motion.

The ramps are all internal to the expression; they are used to implement the delayed trigger. But the final result is not a ramp expression, it is a normal trigger that makes discrete (0 - 1) transitions.

Delaying an entire 'waveform' using only Capytalk is difficult so long as there are no arrays in the language. A delay line implemented on the audio side is simply an array that is treated like a circular buffer, and you need some mechanism like that to create a delay line in capytalk as well. To delay the entire control signal for N milliseconds, you need N storage locations, and in capytalk you have only scalar storage locations, so organizing them into a delay line is impractical.

-Luddy

posted 05 March 2009 16:41            

Unless you prefer to prohibit smiles from all posts

posted 07 March 2009 12:19            

Although totally impractical it would be possible to achieve a delay using a bucket brigade of pairs of capytalk Track and Holds, each passing their value on to the next T&H in the chain, every other millisecond. It would need to be triggered such that while one T&H is holding it's neighboring T&H is tracking and then during the next millisecond they would swap rolls so as to pass data on down the chain.

I say this is impractical as you would need a T&H for every millisecond delay required and it would eat up processing in no time. Feeding it out to a delay module pasted into into another sounds hot parameter would be far less processor hungry and would require a hell of a lot less typing.

posted 09 March 2009 20:03            

You might find something you could re-use in Embrace the Artifact example from the tweaky. Not exactly a CapyTalk array but it does implement a kind of shift-register-with-feedback by capturing values and shifting them through SoundToGlobalControllers using sampleAndHolds as memory locations.

posted 17 March 2009 23:46            

By the way, is there any possibility of having a capytalk interface down at the ASM level (i.e., via the SDK)? AFAIK there is no way to interact directly with capytalk from there, right?

posted 18 March 2009 14:29            

RamWriteandread.kym

When you look at the module cluster it looks hugh but most of this junk is there for no other reason than to display the contents of the ram on the screen at the same time. You would not need all this stuff to use it in for real.

This example has 100 memory cells (it only displays the first five), but there is no reason why you couldn't have millions.

it need Petes DSP and therefore doesn't work on Paca(rana).

BTW the number to index modules is not DSP at all. If you scroll down to the right in the sound file you can see it opened up,(???) and you can see it's just capy talk. the module just makes it easier to generate the index to match the read/write point in RAM.

posted 21 March 2009 13:45            

I'm afraid porting the micro sounds is not down to me alone as I would need a developer kit for the new hard ware and understandably there are a lot more things SSC need to do before tackling the hugh task of producing a new developer kit.

I'm sure they will, someday but I'm happy to wait, not only that I'll have to learn a whole new system, but thats part of the fun.

Carla had already ported over the cross filter long before I even knew there was new hardware on the horizon (it only then dawned on me why she had been asking why I had done some bits the way I did). That in itself must have been a mammoth task as it took me over two years to write in the first place.

That said if there was one Petes DSP module that no one could live without she might think about porting it over, but I can't speak for SSC and there is normally a way to get by using standard kyma modules.

For example the (50 max) multi tap module could be emulated with a script (or the replicater module) calling up 50 Kyma delay lines and three memory writer/reader module pairs to emulate the feed back. You would have to be a bit more careful about reaching clipping but this would just need an attenuator on the input and gain on the output. This would of corse use a lot more (up to 50 times) DSP juice and a lot more RAM but the Paca(rana) has it.

The filter could be made from two memory writer/reader module pairs and some product modules. Once again it would use more DSP juice.

As far as the triggered table read sound is concerned, it's not the reader that is the problem. The reading is done by a Kyma waveshaper module in any case. It's the step writer module that is needed as no Kyma module can write a single sample to an indexed memory location and then stop or start writing under sample rate control ( I believe).

I hope this makes sense

Pete