*Warning*

This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.

Hi Csound Dev's

I wouldn't presume this is a bug, but I have noticed something unusual about using InstrDef and create, that I wonder if it was intentional.

At the moment, it looks like create() compiles instrument body code into an InstrDef and assigns and binds that instrument to both a name variable, and an Instrument number.

If create() is called again, the same named variable is re-bound to whatever the new instrument definition might be, but the instrument number is incremented/reassigned. This can be mitigated somewhat by using delete, although there's no guarantee the new instrument definion gets the old number it used to have.

Here's a simple example:

<CsoundSynthesizer>
<CsOptions>
-odac -d
</CsOptions>
<CsInstruments>
sr = 44100
ksmps = 32
nchnls = 1
0dbfs = 1

instr wrapper
  istamp = p4
  iendamp = p5
    defbody:S = sprintf({{
      aenv linseg %f,p3,%f
      aTone poscil p4*aenv, p5
    out aTone
  }},p4,p5)
  tone@global:InstrDef = create(defbody)
  printfi("tone inum = %f\n",1,nstrnum(tone))
  ;; no deletes
endin

schedule(wrapper,0,1,0,1) 
schedule(wrapper,1,1,1,0)

</CsInstruments>
<CsScore>
f0 2

e
</CsScore>

Output is:
tone inum = 2.000000
tone inum = 3.000000

It's different to 'the old' method of using something like compileorc or evalstr to redefine an instrument definition ( in which case the instrument number is retained).  
I suspect this might also cause issues if I'm routing audio signals between instruments and expect the signal path to follow the order of instrument number.

I acknowledge this might be intentional, in which case, your wisdom on correct usage would be much appreciated.

Thorin