Hi Andres,

CS_VARIABLES are used in two different ways within the system:

* For global vars, the memblock actually holds the memory for the
variable's data

* for instrument local vars, the memBlockIndex describes how much to
index into the INSDS instrument instance to get to the variable's
memory.

The rationale behind this is:

* Moving from CS5 to CS6, it seemed to make sense to introduce the
type system without changing how instrument instances are allocated.
So the type system used the indexes and memBlockSize as info to use
for allocation and wiring up the instances var memory to opcode arg
locations.

* Global vars are unique globally, while local vars are used per
instance.  So we used memblock to actually hold the global var's mem.
This allowed easy adding of new global vars if new ones were added
during multiple parses of orchestra code (i.e. live coding).

I think you should be able to access the var for an instrument
instance by using something like:

     MYFLT *varmem = ip->lclbas + var->memBlockIndex;

You can then cast the varmem to other things depending on the var's type.

Let me know if you have further questions!
steven

On Tue, Apr 8, 2014 at 6:23 PM, Andres Cabrera <mantaraya36@gmail.com> wrote:
> Hi,
>
> I've been working again on the csound debugger, and it's now back to working
> (if you want to have a look see the csdebugger branch), but one of things I
> want to do is show (and allow modification of) variable values. I can get
> the variable pool from the CSOUND struct, and the names and variables are
> right, but it seems that the actual memBlock pointer where data should be is
> always NULL. I'm wondering what's wrong...
>
> The way I am doing it is that when a breakpoint is reached within kperf,
> this causes a breakpoint callback function to be called.
>
> The function called in CsoundQt looks like:
> https://sourceforge.net/p/qutecsound/code/ci/master/tree/src/csoundengine.cpp#l1249
>
> which contains:
>
>       INSDS *insds = csoundDebugGetInstrument(csound);
>       CsoundEngine *cs = (CsoundEngine *) udata;
>       // Copy variable list
>       CS_VARIABLE *vp = insds->instr->varPool->head;
>
> csoundDebugInstrument() is here:
> https://github.com/csound/csound/blob/csdebugger/Top/csdebug.c#L179
>
>
> PUBLIC INSDS *csoundDebugGetInstrument(CSOUND *csound)
> {
>     csdebug_data_t *data = (csdebug_data_t *) csound->csdebug_data;
>     assert(data);
>     return data->debug_instr_ptr;
> }
>
> And the instrument pointer is set within the kperf function when a
> breakpoint is reached:
> https://github.com/csound/csound/blob/csdebugger/Top/csound.c#L1711
>
> if (bp_node->instr == ip->p1) {
>                   if (bp_node->count == 0) {
>                     data->debug_instr_ptr = ip;
>                     data->bkpt_cb(csound, 0, ip->p1, data->cb_data);
>                     data->status = CSDEBUG_STATUS_STOPPED;
>                     bp_node->count = bp_node->skip;
>                     return 0;
>                   }
>
> And this is within the loop that goes through active instances of
> instruments.
>
>     ip = csound->actanchor.nxtact;
> [....]
>
>         while (ip != NULL) {                /* for each instr active:  */
>
> [....]
>
>           ip = ip->nxtact; /* but this does not allow for all deletions */
>         }
>
>
> Any idea what I might be doing wrong?
>
> Cheers,
> Andrés
>
>
>

> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

Great, thanks, that works.

Cheers,
Andrés

On Tue, Apr 8, 2014 at 7:50 PM, Steven Yi <stevenyi@gmail.com> wrote:

Hi Andres,

CS_VARIABLES are used in two different ways within the system:

* For global vars, the memblock actually holds the memory for the
variable's data

* for instrument local vars, the memBlockIndex describes how much to
index into the INSDS instrument instance to get to the variable's
memory.

The rationale behind this is:

* Moving from CS5 to CS6, it seemed to make sense to introduce the
type system without changing how instrument instances are allocated.
So the type system used the indexes and memBlockSize as info to use
for allocation and wiring up the instances var memory to opcode arg
locations.

* Global vars are unique globally, while local vars are used per
instance.  So we used memblock to actually hold the global var's mem.
This allowed easy adding of new global vars if new ones were added
during multiple parses of orchestra code (i.e. live coding).

I think you should be able to access the var for an instrument
instance by using something like:

     MYFLT *varmem = ip->lclbas + var->memBlockIndex;

You can then cast the varmem to other things depending on the var's type.

Let me know if you have further questions!
steven

On Tue, Apr 8, 2014 at 6:23 PM, Andres Cabrera <mantaraya36@gmail.com> wrote:
> Hi,
>
> I've been working again on the csound debugger, and it's now back to working
> (if you want to have a look see the csdebugger branch), but one of things I
> want to do is show (and allow modification of) variable values. I can get
> the variable pool from the CSOUND struct, and the names and variables are
> right, but it seems that the actual memBlock pointer where data should be is
> always NULL. I'm wondering what's wrong...
>
> The way I am doing it is that when a breakpoint is reached within kperf,
> this causes a breakpoint callback function to be called.
>
> The function called in CsoundQt looks like:
> https://sourceforge.net/p/qutecsound/code/ci/master/tree/src/csoundengine.cpp#l1249
>
> which contains:
>
>       INSDS *insds = csoundDebugGetInstrument(csound);
>       CsoundEngine *cs = (CsoundEngine *) udata;
>       // Copy variable list
>       CS_VARIABLE *vp = insds->instr->varPool->head;
>
> csoundDebugInstrument() is here:
> https://github.com/csound/csound/blob/csdebugger/Top/csdebug.c#L179
>
>
> PUBLIC INSDS *csoundDebugGetInstrument(CSOUND *csound)
> {
>     csdebug_data_t *data = (csdebug_data_t *) csound->csdebug_data;
>     assert(data);
>     return data->debug_instr_ptr;
> }
>
> And the instrument pointer is set within the kperf function when a
> breakpoint is reached:
> https://github.com/csound/csound/blob/csdebugger/Top/csound.c#L1711
>
> if (bp_node->instr == ip->p1) {
>                   if (bp_node->count == 0) {
>                     data->debug_instr_ptr = ip;
>                     data->bkpt_cb(csound, 0, ip->p1, data->cb_data);
>                     data->status = CSDEBUG_STATUS_STOPPED;
>                     bp_node->count = bp_node->skip;
>                     return 0;
>                   }
>
> And this is within the loop that goes through active instances of
> instruments.
>
>     ip = csound->actanchor.nxtact;
> [....]
>
>         while (ip != NULL) {                /* for each instr active:  */
>
> [....]
>
>           ip = ip->nxtact; /* but this does not allow for all deletions */
>         }
>
>
> Any idea what I might be doing wrong?
>
> Cheers,
> Andrés
>
>
>

> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

Hi Andres,

I think you should cast the pointer to a STRINGDAT* instead of char*. You could then read the size and data from there.

Let me know how that goes!
Steven

On Apr 10, 2014 3:47 PM, "Andres Cabrera" <mantaraya36@gmail.com> wrote:

Hi Steven,

Should this be the procedure for string variables too?
char *varmem = (char *) (insds->lclbas + vp->memBlockIndex);

I'm not getting the right values here.

Cheers,
Andrés

On Tue, Apr 8, 2014 at 9:19 PM, Andres Cabrera <mantaraya36@gmail.com> wrote:

Great, thanks, that works.

Cheers,
Andrés

On Tue, Apr 8, 2014 at 7:50 PM, Steven Yi <stevenyi@gmail.com> wrote:

Hi Andres,

CS_VARIABLES are used in two different ways within the system:

* For global vars, the memblock actually holds the memory for the
variable's data

* for instrument local vars, the memBlockIndex describes how much to
index into the INSDS instrument instance to get to the variable's
memory.

The rationale behind this is:

* Moving from CS5 to CS6, it seemed to make sense to introduce the
type system without changing how instrument instances are allocated.
So the type system used the indexes and memBlockSize as info to use
for allocation and wiring up the instances var memory to opcode arg
locations.

* Global vars are unique globally, while local vars are used per
instance.  So we used memblock to actually hold the global var's mem.
This allowed easy adding of new global vars if new ones were added
during multiple parses of orchestra code (i.e. live coding).

I think you should be able to access the var for an instrument
instance by using something like:

     MYFLT *varmem = ip->lclbas + var->memBlockIndex;

You can then cast the varmem to other things depending on the var's type.

Let me know if you have further questions!
steven

On Tue, Apr 8, 2014 at 6:23 PM, Andres Cabrera <mantaraya36@gmail.com> wrote:
> Hi,
>
> I've been working again on the csound debugger, and it's now back to working
> (if you want to have a look see the csdebugger branch), but one of things I
> want to do is show (and allow modification of) variable values. I can get
> the variable pool from the CSOUND struct, and the names and variables are
> right, but it seems that the actual memBlock pointer where data should be is
> always NULL. I'm wondering what's wrong...
>
> The way I am doing it is that when a breakpoint is reached within kperf,
> this causes a breakpoint callback function to be called.
>
> The function called in CsoundQt looks like:
> https://sourceforge.net/p/qutecsound/code/ci/master/tree/src/csoundengine.cpp#l1249
>
> which contains:
>
>       INSDS *insds = csoundDebugGetInstrument(csound);
>       CsoundEngine *cs = (CsoundEngine *) udata;
>       // Copy variable list
>       CS_VARIABLE *vp = insds->instr->varPool->head;
>
> csoundDebugInstrument() is here:
> https://github.com/csound/csound/blob/csdebugger/Top/csdebug.c#L179
>
>
> PUBLIC INSDS *csoundDebugGetInstrument(CSOUND *csound)
> {
>     csdebug_data_t *data = (csdebug_data_t *) csound->csdebug_data;
>     assert(data);
>     return data->debug_instr_ptr;
> }
>
> And the instrument pointer is set within the kperf function when a
> breakpoint is reached:
> https://github.com/csound/csound/blob/csdebugger/Top/csound.c#L1711
>
> if (bp_node->instr == ip->p1) {
>                   if (bp_node->count == 0) {
>                     data->debug_instr_ptr = ip;
>                     data->bkpt_cb(csound, 0, ip->p1, data->cb_data);
>                     data->status = CSDEBUG_STATUS_STOPPED;
>                     bp_node->count = bp_node->skip;
>                     return 0;
>                   }
>
> And this is within the loop that goes through active instances of
> instruments.
>
>     ip = csound->actanchor.nxtact;
> [....]
>
>         while (ip != NULL) {                /* for each instr active:  */
>
> [....]
>
>           ip = ip->nxtact; /* but this does not allow for all deletions */
>         }
>
>
> Any idea what I might be doing wrong?
>
> Cheers,
> Andrés
>
>
>

> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel