hi trev -

i think you should be able to measure the performance time via timeinsts and skip the performance if the time is below 0.1 seconds (or which value you find appropriate). something like this:

ktime timeinsts
if ktime < .1 kgoto end
<all your code here>
end:
endin

hope this helps -
        joachim


Am 30.07.2012 03:03, schrieb William Wignall:

Hello Csound Mailing List,

I'm trying to filter out clusters of MIDI notes generated by physical
note attacks. There's usually a cluster of them at the beggining, so I'd
like to ignore them - not delay them! Is there an opcode or process that
will ignore data for a given period of time, then start ouptutting data?
Please see attached CSD. I'd like to put this on line 51.

--
Trev Wignall

Send bugs reports to the Sourceforge bug tracker
           https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Thanks, I'll try it out.

On Mon, Jul 30, 2012 at 4:47 AM, joachim heintz <jh@joachimheintz.de> wrote:

hi trev -

i think you should be able to measure the performance time via timeinsts and skip the performance if the time is below 0.1 seconds (or which value you find appropriate). something like this:

ktime timeinsts
if ktime < .1 kgoto end
<all your code here>
end:
endin

hope this helps -
        joachim


Am 30.07.2012 03:03, schrieb William Wignall:

Hello Csound Mailing List,

I'm trying to filter out clusters of MIDI notes generated by physical
note attacks. There's usually a cluster of them at the beggining, so I'd
like to ignore them - not delay them! Is there an opcode or process that
will ignore data for a given period of time, then start ouptutting data?
Please see attached CSD. I'd like to put this on line 51.

--
Trev Wignall

Send bugs reports to the Sourceforge bug tracker
           https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

--
Trev Wignall

>  ckgoto (ktr == 1), wait
>
> wait:
>
> reinit reset

I have a fix, not tested with your csd but I think that the follow
change works:

  ...
  if (ktr == 1) then
      reinit reset
      kgoto  reset
  endif
  ...

instead of `ckgoto ... wait'. The solution with `ckgoto' is

  ...
  ckgoto (ktr != 1), cont
  reinit reset
  kgoto  reset
  cont:
  ...

It is the same but if-then seems clearest.
`kgoto reset' avoids the pass after `rireturn', when `ktime' is zero.
A proof of concept is

<CsoundSynthesizer>
<CsInstruments>

sr = 44100
kr = 10

instr 1

reset:
  prints "=== start ===\n"
  ktime  timeinsts
  if (ktime < 1) kgoto end
  rireturn

  if (ktime >= 2) then
    reinit reset
    kgoto  reset
  endif

  printk2 ktime

end:

endin

</CsInstruments>
<CsScore>
i1 0 5.9
</CsScore>
</CsoundSynthesizer>

csound -n test.csd
...
new alloc for instr 1:
=== start ===
 i1     1.00000
 i1     1.10000
 i1     1.20000
 i1     1.30000
 i1     1.40000
 i1     1.50000
 i1     1.60000
 i1     1.70000
 i1     1.80000
 i1     1.90000
=== start ===
 i1     1.00000
 i1     1.10000
 i1     1.20000
 i1     1.30000
 i1     1.40000
 i1     1.50000
 i1     1.60000
 i1     1.70000
 i1     1.80000
 i1     1.90000
=== start ===
 i1     1.00000
 i1     1.10000
 i1     1.20000
 i1     1.30000
 i1     1.40000
 i1     1.50000
 i1     1.60000
 i1     1.70000
 i1     1.80000
 i1     1.90000
...

tito

Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Tito- your code works, timeinst will reset for a new note. There's a problem though. I need to play very slowly to get generate any MIDI notes. But, if I make the amount of time shorter than it will ignore my playing completely except for notes falling on bow changes. It will also start generating notes that are a half step off. It seems like it's tripping over itself or something... Is there an easier way to do this? All I really need is a silencing gate at the beginning of each physically played note.


if (ktime < .1) kgoto end     --->   Have to play very slowly

-versus-

if (ktime < .01) kgoto end ----> Ignores everything except for bow-change notes and will also start producing erroneous notes

Joachim- I don't know how to code subinstruments, and I wouldn't know where to start with something like that... I do in fact want to filter out extremely fast changing values but I have already tried port/portk and those opcodes generate so many MIDI notes at once that Kontakt will behave erratically. It seemed to be the wrong approach when I first tried it.

On Wed, Aug 1, 2012 at 6:14 AM, Tito Latini <tito.01beta@gmail.com> wrote:

>  ckgoto (ktr == 1), wait
>
> wait:
>
> reinit reset

I have a fix, not tested with your csd but I think that the follow
change works:

  ...
  if (ktr == 1) then
      reinit reset
      kgoto  reset
  endif
  ...

instead of `ckgoto ... wait'. The solution with `ckgoto' is

  ...
  ckgoto (ktr != 1), cont
  reinit reset
  kgoto  reset
  cont:
  ...

It is the same but if-then seems clearest.
`kgoto reset' avoids the pass after `rireturn', when `ktime' is zero.
A proof of concept is

<CsoundSynthesizer>
<CsInstruments>

sr = 44100
kr = 10

instr 1

reset:
  prints "=== start ===\n"
  ktime  timeinsts
  if (ktime < 1) kgoto end
  rireturn

  if (ktime >= 2) then
    reinit reset
    kgoto  reset
  endif

  printk2 ktime

end:

endin

</CsInstruments>
<CsScore>
i1 0 5.9
</CsScore>
</CsoundSynthesizer>

csound -n test.csd
...
new alloc for instr 1:
=== start ===
 i1     1.00000
 i1     1.10000
 i1     1.20000
 i1     1.30000
 i1     1.40000
 i1     1.50000
 i1     1.60000
 i1     1.70000
 i1     1.80000
 i1     1.90000
=== start ===
 i1     1.00000
 i1     1.10000
 i1     1.20000
 i1     1.30000
 i1     1.40000
 i1     1.50000
 i1     1.60000
 i1     1.70000
 i1     1.80000
 i1     1.90000
=== start ===
 i1     1.00000
 i1     1.10000
 i1     1.20000
 i1     1.30000
 i1     1.40000
 i1     1.50000
 i1     1.60000
 i1     1.70000
 i1     1.80000
 i1     1.90000
...

tito

Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

--
Trev Wignall

In the follow change I use an accumulator for the triggers (ktr).
If the value of the accumulator is positive after ~ 15 msec (quantized
with kr), the trigger for midion2 (ktr_filtered) is 1 otherwise it is 0.
It avoids multiple triggers within 15 msec (you can change this limit).

The `reinit/rireturn' code is useless in this case and it is to remove.

...
itr_delay       = 0.015
icycles_limit   = itr_delay * kr
kcycles         init 0
ktr_accum       init 0
ktr_filtered    init 0

if (kcycles > icycles_limit) then
    ktr_filtered = (ktr_accum > 0 ? 1 : 0)
    ktr_accum = 0
    kcycles = 0
else
    ktr_accum = ktr_accum + ktr
    kcycles = kcycles + 1
endif

/*      MIDI Out        */

kchn = 1

;; knum is -35 when kpch is zero
if knum > 0 then
    midion2 kchn, knum, kvel1, ktr_filtered
    ktr_filtered = 0
endif

...

tito


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Great. I'm seeing a little simplification

  ktr_filtered = ktr_accum

instead of

  ktr_filtered = (ktr_accum > 0 ? 1 : 0)

My head was around an unitary trigger.

There are some variations of the prior solution but I don't see
differences in the performance. Feel free to use what you want

...
itr_delay       = 0.015    ; 15 msec

icycles_limit   = itr_delay * kr
kcycles         init 0

k_have_trigger  init 0

ktr_filtered    init 0

if (kcycles > icycles_limit) then

    ktr_filtered = k_have_trigger
    k_have_trigger = 0
    kcycles = 0
else
    if (k_have_trigger == 0 && ktr != 0) then
        k_have_trigger = 1
    endif
    /*
     *  another possibility is
     *
     *     k_have_trigger = k_have_trigger | ktr
     *
     *  however there are only details
     */

    kcycles = kcycles + 1
endif

...

tito

On Fri, Aug 03, 2012 at 01:20:23AM -0400, William Wignall wrote:
> Tito-
>
> This works beautifully. I can't thank you enough! This issue had been
> bothering me for quite some time and I'm sure that I would not have been
> able to come up with it on my own for a few weeks or months.
>
> Trev
>
> On Thu, Aug 2, 2012 at 6:17 AM, Tito Latini <tito.01beta@gmail.com> wrote:
>
> > In the follow change I use an accumulator for the triggers (ktr).
> > If the value of the accumulator is positive after ~ 15 msec (quantized
> > with kr), the trigger for midion2 (ktr_filtered) is 1 otherwise it is 0.
> > It avoids multiple triggers within 15 msec (you can change this limit).
> >
> > The `reinit/rireturn' code is useless in this case and it is to remove.
> >
> > ...
> > itr_delay       = 0.015
> > icycles_limit   = itr_delay * kr
> > kcycles         init 0
> > ktr_accum       init 0
> > ktr_filtered    init 0
> >
> > if (kcycles > icycles_limit) then
> >     ktr_filtered = (ktr_accum > 0 ? 1 : 0)
> >     ktr_accum = 0
> >     kcycles = 0
> > else
> >     ktr_accum = ktr_accum + ktr
> >     kcycles = kcycles + 1
> > endif
> >
> > /*      MIDI Out        */
> >
> > kchn = 1
> >
> > ;; knum is -35 when kpch is zero
> > if knum > 0 then
> >     midion2 kchn, knum, kvel1, ktr_filtered
> >     ktr_filtered = 0
> > endif
> > ...
> >
> > tito


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Another possibility is to use the `kamp / krms' value in

  krms rms asig1

to skip some pitch. It is a raw way to measure the harmonicity
of the audio input in your csd. The time-window of `rms' is 1/kr,
~ 0.0003 with sr=44100 and ksmps=16. It is ~ 0.001 (= iupdte)
with ksmps=44.

tito


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"