Author |
Message |
selvmarcus
Joined: Feb 08, 2006 Posts: 121 Location: Berlin, Germany
G2 patch files: 39
|
|
Back to top
|
|
|
cebec
Joined: Apr 19, 2004 Posts: 1098 Location: Virginia
Audio files: 3
G2 patch files: 31
|
Posted: Tue Mar 14, 2006 2:12 pm Post subject:
|
|
|
haha, that's so cool! |
|
Back to top
|
|
|
mosc
Site Admin
Joined: Jan 31, 2003 Posts: 18197 Location: Durham, NC
Audio files: 212
G2 patch files: 60
|
Posted: Tue Mar 14, 2006 2:36 pm Post subject:
|
|
|
Very neat. I've often wished for a builtin module to do something like that. It would make debugging patches easier to have a scope, or even a meter. Good patch... _________________ --Howard
my music and other stuff |
|
Back to top
|
|
|
3phase
Joined: Jul 27, 2004 Posts: 1183 Location: Berlin
Audio files: 13
G2 patch files: 141
|
Posted: Tue Mar 14, 2006 6:37 pm Post subject:
|
|
|
wow !
You are operating on this highclock speeds..whooo
Do i get that right that this thing is sampling at 96 k?
So this Delta things give in audio mode a one sample pulse and the delta yellow gives an 8 samples long pulse with 2 samples delay ?
Is the measuring so acurat? puhhh..
I had problems to get certain seq things working on a 16th clock speed...
I think your technologie might have some solutions for certain sequencer problems.
thanx for the interesting lesson in low level patching
and btw: the problem with the last step could be related to the note sequencers tendencie to be a tiny bit late with the note readout...
I inserted a pulse module on the trigger output and it seemed to help also on such highprecission levels... |
|
Back to top
|
|
|
selvmarcus
Joined: Feb 08, 2006 Posts: 121 Location: Berlin, Germany
G2 patch files: 39
|
Posted: Tue Mar 14, 2006 8:15 pm Post subject:
|
|
|
Yes, 96k.
By the way:
A delta pulse in signal processing terminology is the shortest
pulse you can create. In the continuum it has in idea zero length,
but a certain height (1 unit) and carries indeed some energy,
equally spaced over the whole frequency spectrum.
Any signal can be considered as constructed of an inifinite sum of
time-shifted and amplified delta pulses.
The circuit in my patch works because of feeding back of
the flip-flop output into the reset input. So its set,
and almost immediatly reset by itselv.
I think the patch compiler generates a 2 streams of dsp instructions,
2 different streams for control-rate and audio-rate parts.
The control stream is only called every 4th audio-clock interrupt.
If there any loops in the patch, extra memory locations
are introduced by the compiler to hold intermediate values for the next
big cycle.
This way you get a one-sample delay when you
patch i.e the output of a mixer into one of its own inputs,
which is usefull for diy filters and so on.
Chains of modules with no patch-loops are computed in
one rush with no sample delay. So a chain of 10 modules
can sync with one of three modules with no problem,
much different from the hardware world.
And much easier to use!
-----
Marcus |
|
Back to top
|
|
|
selvmarcus
Joined: Feb 08, 2006 Posts: 121 Location: Berlin, Germany
G2 patch files: 39
|
Posted: Tue Mar 14, 2006 8:23 pm Post subject:
|
|
|
Can you specify the "tiny" a bit more ?
Maybe we can have a look with the scope?
----
Marcus |
|
Back to top
|
|
|
3phase
Joined: Jul 27, 2004 Posts: 1183 Location: Berlin
Audio files: 13
G2 patch files: 141
|
Posted: Wed Mar 15, 2006 7:13 am Post subject:
|
|
|
No, sorry...
It´s just that with all my sequencer experiments i often had to add sample and holds or the smallest possible delays (by adding pulse or delay modules in minimal setting) to the note sequencers to make them working the way i ve expected them to work. My idea was that the note output is a bit late..But maybe there are other reasons. |
|
Back to top
|
|
|
selvmarcus
Joined: Feb 08, 2006 Posts: 121 Location: Berlin, Germany
G2 patch files: 39
|
Posted: Thu Mar 16, 2006 1:33 pm Post subject:
|
|
|
There seems to be a bug so the trigger does not catch up at the first few samples, sometimes. You can see it with
the decaying sine demo (3). After several "shots" it looks alright, though.
Work in progress... might take some days.
Will also introduce a variable trigger delay time for "knowing what was going on before, or much later"
Maybe two channels.
---
Marcus |
|
Back to top
|
|
|
Rob
Joined: Mar 29, 2004 Posts: 580 Location: The Hague/Netherlands/EC
G2 patch files: 109
|
Posted: Mon May 08, 2006 3:58 am Post subject:
|
|
|
selvmarcus wrote: | I think the patch compiler generates a 2 streams of dsp instructions,
2 different streams for control-rate and audio-rate parts.
The control stream is only called every 4th audio-clock interrupt.
If there any loops in the patch, extra memory locations
are introduced by the compiler to hold intermediate values for the next
big cycle.
Marcus |
It is a bit different, at every interrupt at the 96kHz sample rate all red/orange modules are calculated, but only a quarter of the blue/yellow ones.
So, 1/24000 of a second it looks like this:
With no blue modules:
red-wait, red-wait, red-wait, red-wait
With many blue modules at full patchload:
red-1/4blue, red-1/4blue, red-1/4blue, red-1/4blue
With blue modules but half patchload:
red-1/4blue-wait, red-1/4blue-wait, red-1/4blue-wait, red-1/4blue-wait
This implies a problem when mixing red and blue signals, it is implossible to say in which of the four possible gaps between red calculation rounds a blue or yellow module is calculated, as calculated blue/yellow results become available immediately and not after four red-1/4blue cycles have passed.
This already applied to the classic Modular, but on the G2 things have improved by two major changes; first is the sorting algorithm that defines the calculation order and second is the fact that one can now trust that for a module next in the line there is no input-output delay for a previous module. Meaning that when the output of a module is subtracted from its input by a module further up the chain you get the real difference of a value and its processed value, and not a difference of a value and its processed Z-1 value. This should apply for both red and blue modules.
Still for one single module the difference between its own output and one of its own inputs will be that its output will be the processed Z-1 value, as a module cannot foresee the future. This always applies for both red and blue modules.
For triggered inputs it is a bit different, as some triggered inputs only set up a condition that will start to apply only after a signal on another input, e.g. the reset inputs on the sequencer modules work this way. There is some subtle stuff going on there that sometimes makes behavior seem buggy, but at other times saves one's ass without one knowing.
/Rob |
|
Back to top
|
|
|
selvmarcus
Joined: Feb 08, 2006 Posts: 121 Location: Berlin, Germany
G2 patch files: 39
|
Posted: Wed May 17, 2006 7:14 pm Post subject:
|
|
|
Thanks Rob, for clarifying this!
My scheme would not work, because amount of processing has to be equal for each interrupt. It might be possible to buffer samples to unhook from interrupt... but there probably is good reason why they are doing it this way.
So we have to live with it.
/Marcus _________________ Something with this universe is somehow perfectly sound and in order. |
|
Back to top
|
|
|
|