Re: [Denemo-devel] Transpose

[Richard Shann]

On Tue, 2008-08-12 at 10:49 -0500, Jeremiah Benham wrote:
> shows a structure defined in the .i file like this
> typedef struct {
>      double x,y,z;
> } Vector;
> 
> I will have to play around with it. The memory will have to be freed
> somehow.
There will be lots of possibilities to cause trouble, but it looks very
easy to use sensibly whereupon no such issues would arise.
>  
> 
> > and indeed to invoke a function with some
> > other type from the language would require some way of expressing
> the
> > value of a custom type in the scripting language. 
> 
> I believe that can be done.  
I've had a look at this, and this and all the other issues I've raised
have (perhaps not surprisingly) been covered - for example namespace
clashes are covered.
At this page
http://www.swig.org/Doc1.1/HTML/SWIG.html#n3
there is the stuff on structures... here is a quote

If SWIG encounters the definition of a structure or union, it will
create a set of accessor functions for you. While SWIG does not need
structure definitions to build an interface, providing definitions make
it possible to access structure members. The accessor functions
generated by SWIG simply take a pointer to an object and allow access to
an individual member. For example, the declaration :

        struct Vector {
                double x,y,z;
        }
        
gets mapped into the following set of accessor functions :

        double Vector_x_get(Vector *obj) {
                return obj->x;
        }
        ....
        
So, by including denemo.h we could access the cursor_x field of a Note and so 
on. 
****HOWEVER****,
we would then start to expose all the innards of Denemo, which I would not like 
to try
answering questions on. That is, I think this would lure people into writing 
scripts which
seem to work but then things would start to break and crash and fixes would
result in everything getting more and more complicated.
If instead we provide our own accessor functions to things we think we 
understand, with names
that make sense to us, I think we have a better chance of preventing things 
getting too complex
to manage.
This comes back to what I said when you first proposed scripting: the core of 
Denemo would be
be a nightmare to write scripts against, because there is no clear model, and 
what there is
was not designed for the sort of manipulations we would want to do.
Instead, at the higher level, there are operations that we do understand - 
delete a note,
insert a note, and (to some extent) edit a note, for example. If we stick to 
manipulating Denemo
at this level then all the stuff below will continue to do its work. So for 
example to transpose
a section we would move the cursor from object to object and, if it is a chord 
read out pitch
information, and apply edit functions to the chord (ie the edit functions that 
apply to
si->currentobject). Some edit functions we don't have yet (e.g. there is 
up-an-octave
but not up-an-arbitrary-interval), but we could and should write those.

So, in summary, I would say:
        Do not include denemo.h in the interface
        Do write some more edit and accessor functions
                dnm_get_pitch(DenemoNote *note) etc 
        Include these in the interface.
But first, let's just see it doing simple things without parameters and so on.
Richard