The midiarp thing

Developers
#1

Hi Rory,
i think something is not right with midiarp.
I tried the different settings for kMode, and
kNote, kTrigger midiarp kTempo, 1
was very problematic.
Can you check please?

#2

I will. Are you just testing with the sample .csd file?

#3

yes- but you have to add kMode.
And can you also test if kMode is really k rate?

1 Like
#4

I wish I had read this before spending the last 20 minutes wondering why the hell kMode wasn’t doing anything :rofl:

I don’t noticed any problems wehn kMode is 1. Here is the output from a C chord, with staggered entry of each note (which explains what’s happening at the start):

instr 300:  p5 = 48.000
instr 300:  p5 = 48.000
instr 300:  p5 = 52.000
instr 300:  p5 = 48.000
instr 300:  p5 = 57.000
instr 300:  p5 = 48.000
instr 300:  p5 = 57.000
instr 300:  p5 = 60.000
instr 300:  p5 = 48.000
instr 300:  p5 = 52.000
instr 300:  p5 = 57.000
instr 300:  p5 = 60.000
instr 300:  p5 = 48.000
instr 300:  p5 = 52.000
instr 300:  p5 = 57.000
instr 300:  p5 = 60.000
instr 300:  p5 = 48.000
instr 300:  p5 = 52.000
instr 300:  p5 = 57.000
instr 300:  p5 = 60.000
instr 300:  p5 = 48.000
instr 300:  p5 = 52.000
instr 300:  p5 = 57.000
instr 300:  p5 = 60.000
instr 300:  p5 = 48.000

But I do note that updating kMode in perf time is not working. :thinking:

#5

Actually, I was able to get kMode working without having to modify the source code. Can you try this example and MIDI file?

Chord.MID (67 Bytes)

midiarp2.csd (1.1 KB)

#6

midiarp2.csd proves that it does work, at k rate, and

giModes ftgen 1, 0, 4, -2, 0, 1, 2, 3
kModeIndex phasor .1
kMode tab kModeIndex, giModes, 1
is an interesting appraoch- as i was using
kMode 0, p3, 3.99

but think
kNote, kTrigger midiarp kTempo, 1
should just work as well.
Here it struggles :

Also Mode 2 does not work right?

#7

Hmm, this is all working fine for me. I don’t hear any of the problems you’re facing. Let me double check that my source matches the latest dev tip…

#8

my build is -Csound version 6.15 (double samples) May 4 2021

#9

Sorry, it seems that passing 1 directly also makes a mess of things here. How strange. Leave it with me. And yes, the random stuff does seem to move towards not being very random!

#10

ha…i get a kick from it every time to establish i am not going crazy :slight_smile:

i’d be glad to test the test!

#11

And now pulseaudio crapped itself and can no longer see any devices :rage: Has there ever been a more useless application.

#12

This might hurt then, because mode 2 and 3 seems to work fine for me :rofl: I thought mode 2 was supposed to be random. Hence my stating earlier that is doesn’t work. For me it descends through the notes without issue. I’m still in the dark as to why passing 1 causes such a strange result.

#13

Looking better now I think.

I just updated the dev tip. Can you pull and try it again?

#14

Works perfectly now, using my example:
instr 200

kTempo = 8
kMode   line    0,p3,3.99
kNote, kTrigger midiarp kTempo, int(kMode)
printk2 int(kMode)
kFilterFreq lfo 2000, .05, 1
;if kCounter is 1 trigger instrument 300 to play
if kTrigger==1 then 	
    event "i", 300, 0, .5, .5, kNote, abs(kFilterFreq)+200
endif

endin

also tried, with all values for kMode: 0,1,2and 3- all works.

I will remove the section Initialization and move kRate and kMode over to the Performance section.
Then i can close the issue.

I like this opcode, but i wonder if it would be possible to have such an opcode but for non-midi material…i guess grain could do it…


…had some fun here…

#15

Ha, that’s nice. I never really used this opcode, but I think I might start!