Dear OMchromists,
I would like to apply a user-fun to change (set or modify) the value(s) of a slot of type cs-table in a chroma-matrix via user-fun (e.g. for changing amplitude envelopes (aenv)). So far I could not succeed as the value retrieved from the component is a table number, not the object used for setting anymore. Any ideas anyone what to do in this case?
Thank you 
M
omchroma-userfun-example.omp (19.3 KB)
Dear Marlon,
the simplest solution I have is this one (see the screenshot attached).
Best,
Francesco
Hi,
Thanks, but this is not exactly what I was looking for. In fact, it just passes on the table number (which becomes the first value of the y-points list of the bpf), thus using t. It still leaves the problem of how to process tables in omchroma matrices with a user-fun - as all we can deal with in the user-fun it seems are table numbers (references), not the data itself.
Maybe somehow construct tables based on data retrieved from the matrix and provide them to synthesize directly while referring through them in the user-fun via numbers… (kind of defeating the ergonomics of the user-fun though)?
Cheers,
M
Dear Marlon,
can you enlighten me about what you mean for the “data itself”? If the y-points list of the bpf controls aenv and the sound is synthesized on the base of these data (i.e. the y-points list), it seems to me that the user-fun is not operating just on table numbers. But maybe I’m missing something important, so forgive me. Here’s the .sco obtained with your BPF 3
;This synthesis process called uf2_A started on 3 3, 2016 - AT 19:53 (27 sec)
; Global Variables: sr = 44100, kr = 44100, ksmps = 1, nchnls = 1
; Defined by chroma classes:
; GEN functions *****
; audio wave
f1 0 65537 10 10
; Loaded tables:
; Generated tables:
;------ Lines for event n. 1 --------
f 1000 0 4097 7 0.0000 2048.0 100.0 2048.0 0.0000
i1 0.000 1.000 -6.000 440.000 1000.000 1000.000
The table written into the score (f 1000) has nothing to do with the user fun. The user-fun simply extracts the value from the component and (after the “detour” of a becoming the y-value of a point in the BPF) writes the same value back: extracted value for aenv is number 1000, then this number is used to set the slot “y-points” of the BPF. This value is now used again to set the slot “aenv”, hence the same value as it originally had. This process can be followed quite easily by connecting prints here and there in the user-fun.
The question how to specify a table for a slot of type cs-table (such as “aenv”) in a user-fun still remains…
Cheers,
M
You’re right. The raison d’être of the user-fun is mysterious because the so-called solution I proposed gives only the same results that you can achieve connecting the bpf to the aenv red slot directly (see image)…
Hello, Marlon,
It is not (yet?) clear what you wish to do (and why you need to do it in a user-fun). Would you like to change the table of a slot of type cs-table (by giving another table, for instance), or to modify the values of a stored table? The value 1000 (see above) is the f-table number (computed by default and whose starting number is set in the preferences of OM).
A user-fun is a sort of (potentially) intelligent loop on each component before they are synthesized, but after that their value is computed. Having access, at the same time, to the current component as well as to the whole matrix, it is easy to program several automatic rules depending on the . Of course, one can also do it in the slot. If the rules are simple, it is almost the same, but if they are complex, it rapidly turns to a cumbersome solution.
I’m sure, however, that a solution must exist (perhaps in Jean’s neurons…:-)!
Marco
Hi there,
The user-fun applies relatively late in the process (just when the data is converted into actual Csound score lines).
At this moments the tables have already been “prepared” (= written textually in the header and replaced with tables numbers in the data).
So I don’t see a better solution than the one Marlon proposed already : declare additional tables using the synthesize keyword “:tables” and just deal with table numbers in the user-fun…
Jean
Hello!
The actual reason in my case is to add a bit of extra time for a reverb-tail by adding to the duration of the component and modifying its aenv by adding a point after the last point (ps OMPrisma’s function “add-dur” does this) - I think it’s a good example case for when one wants to apply the same global modification to every matrix component in a post-process. I could also see other similar cases, e.g. to add a number of components and modify their aenv so each of them has a steeper “fadeout”. This can of course also be done directly in the matrix but it’s a bit cumbersome from a user’s point of view having to deal with reverb-tails explicitly when setting the matrix. Maybe there’s a way for doing this in csound (Karim? :)?
Cheers,
M
You raise an interesting issue, Marlon, which should be discussed within the developers of OMChroma, that is, whether it is possible to apply a user-fun earlier in the computational process. This will take some time, however.
In the meanwhile, if your instrument has an added reverb, the typical solution (within csound), would be to separate the reverb part from the DSP part (which makes the sound) and write two instruments within the orchestra. The DSP instrument might send its data to a ga-var (global, a-type), rather than to the output, the reverb instrument (which should have a higher instrument number in the orchestra, typically, this was 99) will read from this ga-var and can be given a longer duration (as long as you wish), with respect to the DSP instrument (see, for instance, http://www.csounds.com/manual/html/reverb.html). Luca Richelli used communicating instruments within OMChroma very successfully.
I hope that this will help you find a less cumbersome solution than pre-processing all your data in the matrix itself.
Cheers!
Marco