[Csnd] Workflow to set MIDI Presets

The Csound Mailinglist
1

Hello everybody!

I’m wondering what your workflows are to create and recall presets for MIDI for live situations.

I want to work with MIDI encoder and motorized faders.
When i call an instrument i want to set my encoder and fader to predefined values.
in which way can i set my presets?
i found out that ctrlprint can save values to a text file. but how can i use this text file for recalling a preset?
or is there an more friendly way?

Greetings
Philipp
Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        Issues · csound/csound · GitHub
Discussions of bugs and features can be posted here

2

Hi Philipp,
there are a few ways to solve this. The basic idea, I can see, is to
create a kind of SysEx vector, i.e. a list of your controllers, always
stored and sorted in the same way. Unused controllers would be set to
default values.

As for save and load: you can print values to text files, using your
method or fprints or possibly others. Text files can be loaded into a
table with GEN23. There is also ftsave and ftload.

You can create preset-number based filesnames with sprintf or the str*
functions like strcat and similar.

The actual mechanism: it might be best to have dedicated load/save
instruments. A load instrument would load the data and then go through
the whole list of controller values at i-time to set your motorised
faders.

Passing data around: at some point a table is involved. You only need
one active table for the currently loaded preset. You can use a global
table giTable, you can use a local table, created in a persistent way
(ftgen or ftload) and pass the table number around through a channel
(chn opcodes), through one global variable, through parameters (a bit
awkward perhaps) or ... You can copy the loaded values to a global array
and work on that. If there aren't too many controllers you can copy them
to channels (chn again). All this means that your preset data is
available anywhere inside your orchestra.

NOTE: for channels, be sure to use a good naming scheme (strcat/sprintf can work
wonders), perhaps with names like:
mysynth.filter
or
mysynth.cc0
or something even more structured.

I hope that some of that helps. Whether you use straight ftables,
channels, a global array or another system, depends on your personal
workflow and preference. They can all be quite ellegant and well
maintainable. A separate load and save instrument is advised! You can
build a save+load instrument with a bit of control flow (if statements)
and good parameters (p-fields). This instrument would most likely work
at i-time. You can use turnoff at the end of your instrument, so it will
only run as long as required. You may want to set a global flag (channel
or whatever) to indicate readiness. That might be set to 0 or off when
you begin to load and set to 1/on when everything is loaded. That's
optional though. It depends on your needs and preferences again.

Best wishes,

Jeanette

3

Hey Jeanette,

thanks a lot for this precise description!

In the meanwhile i was working with some opcodes that were designed for this task. With a little research i got my head around this.
And i guess i have the solution for this

But now i get some „Segmentation fault“ error and it doesn’t work and i don’t know why.

Here is my code, maybe someone can help:

<CsoundSynthesizer>
<CsOptions>
-m0d
-d -odac -W -3 -+rtmidi=portmidi -Ma -Q0
</CsOptions>
<CsInstruments>
sr = 44100
ksmps = 32
nchnls = 2
0dbfs = 1.0

massign 0, 0

opcode getMidiNote, k, k
  kChannel xin

  kStatus, kChan, kData1, kData2 midiin
  kMidiNote init 0
  if kStatus == 144 && kChan == kChannel then
    kMidiNote = kData1
  endif
  
  xout kMidiNote
endop

#define UPDATE_CC(Chn'CC)

4

Hi Philipp,
thanks for pointing out these opcodes. I never paid any attention to them, but they look really helpful.

I can see one possible issue, that is your call to ctrlpreset. The manual, even the online version gives the syntax as:
kpreset ctrlpreset ktag, kchnl, kctlno1, [kctlno2] [, kctlno3] ...
So there is no array version documented, which might just work, but the second input parameter is the channel, which I suppose is not saved in the data array, so you may try with at least 1 as the second parameter:
kPreset ctrlpreset p4, 1, gkMidiData

Otherwise a neat solution.

One point, which is pure curiosity: why did you chose a UDO to read the note values and a macro to update the MIDI CC values? Coincidence or design?

Best wishes,

Jeanette

5

Sorry, a P.S. experimenting with ctrlprint and ctrlsave, I found that the array has the following structure:
number_of_ccs, channel(apparently), 11_number, cc_value, cc_number, cc_value
This might lead to issues. Try to substitute the array in your call with at least certain elements from your array:
ctrlpreset p4, 1, gkData[2], gkData[4], ...

Perhaps that helps.

Best wishes and aplogies again for the continued reply,

Jeanette

6

Hi Philipp,
this works for me:

-odac sr = 44100 ksmps = 32 nchnls = 2 0dbfs = 1.0

ctrlinit 1, 10,9, 11,78, 12,47, 13,101, 14,62, 15,92, 16,33, 17,74

opcode getMidiNote, k, k
kChannel xin

kStatus, kChan, kData1, kData2 midiin
kMidiNote init 0
if kStatus == 144 && kChan == kChannel then
kMidiNote = kData1
endif

xout kMidiNote
endop

#define UPDATE_CC(Chn’CC)

7

Hey all!

I can see one possible issue, that is your call to ctrlpreset. The manual, even the online version gives the syntax as:
kpreset ctrlpreset ktag, kchnl, kctlno1, [kctlno2] [, kctlno3] …

In the manual as example is the array version used. And it’s working. The manual is not that precise with these opcodes.When you print this with ‚ctrlprintpresets‘ you get the right syntax, even with the preset number and channel.

One point, which is pure curiosity: why did you chose a UDO to read the note values and a macro to update the MIDI CC values? Coincidence or design?

I’m still experimenting with how i can streamline some of my code blocks. I guess, when i have this running i will use it very often.
I allredy have some midi input related UDOs but maybe i will combine these UDOs and some macros. i don’t know yet.

You might consider altering schedkwhen to schedule.

Schedkwhen was definitley a problem! i used ‚event’ now for this.

And with my i code later in the mail i also got it running. But it’s still not reliable enough, or i don’t get how ctrlpreset and ctrlprintpresets is executed.

So can someone who worked on these opcodes explain me what is happening there?
When i write the preset file with ‚ctrlprintpresets‘, i get a new ‚block‘ of presets every time i call csound new and save new presets.
How is ctrlpreset handling these blocks? is it just reading the newest one?

As example:

first call of csound

kpre41 ctrlpreset 41 , 1, 10, 64, 11, 127, 12, 0, 13, 0, 14, 0, 15, 0, 16, 0, 17, 0

second call
kpre41 ctrlpreset 41 , 1, 10, 64, 11, 127, 12, 0, 13, 0, 14, 0, 15, 0, 16, 0, 17, 0

kpre42 ctrlpreset 42 , 1, 10, 64, 11, 127, 12, 0, 13, 0, 14, 0, 15, 0, 16, 0, 17, 0

third call
kpre41 ctrlpreset 41 , 1, 10, 127, 11, 0, 12, 0, 13, 0, 14, 0, 15, 0, 16, 0, 17, 0

fourth call
kpre41 ctrlpreset 41 , 1, 10, 127, 11, 0, 12, 0, 13, 0, 14, 0, 15, 0, 16, 0, 17, 0

kpre42 ctrlpreset 42 , 1, 10, 127, 11, 127, 12, 127, 13, 0, 14, 0, 15, 0, 16, 0, 17, 0

Another question related to this opcode:

How much time needs it to write to the file?
I just wanted to call a designated instrument just for one k-cycle to write a new preset. Is this enough?

Also sometimes when i saved a preset to the file ‚ctrlpreset‘ is not able to call it. I don’t know yet what is happening there.

This iy my code right now:

-m0d -d -odac -W -3 -+rtmidi=portmidi -Ma -Q0 sr = 44100 ksmps = 32 nchnls = 2 0dbfs = 1.0

#define UPDATE_CC(Chn’CC)

8

Hi Philipp!
Apr 18 2024, Philipp Neumann has written:
...

How much time needs it to write to the file?
I just wanted to call a designated instrument just for one k-cycle to write a new preset. Is this enough?

Why bother, you already use turnoff. This gives the instrument enough
time to complete. Who knows depending on certain circumstances, it might
take a little more or a little less. Give the instrument a p3 or .1 or
maybe even .01 and leave the rest to the real world in this instance.

That's the theory and practise has proved it so far, for me.
...

Best wishes,

Jeanette