Re: [Denemo-devel] Current state and plans

[Richard Shann]

Another topic relevant to this general discussion is the question of
scripts interfering (and co-operating) with each other.
I have been looking at this, as my figured bass filter started
conflicting with a "move on edit" filter.
We will need to agree standards to prevent scripts over-writing each
others variables.
There are two tactics that I have come across:
        1) using let, let* and friends to make variables local
        2) adopting a convention that all variables in a script have names
starting 
        <scriptname>::varname   (<scriptname> being the command that is being
implemented - these have to be unique)

(here, I am assuming that :: does not have some special syntactical
meaning in Scheme - I saw something about : and modules somewhere in the
docs so that would need investigation).

Using this we should be able to call scripts more than once and be able
to rely on functions we have defined still being valid. Here is the
current state of my figured bass filter, which shows the use of tactic
(1), but not (yet) tactic (2)
The script acts as a toggle - each time you call it, it starts/stops
filtering. I include it here just to illustrate the point, it needs some
additional code to operate.
Richard
;;;;;;;;;;;;
;;; Figured Bass filter
(use-modules (srfi srfi-13))

(if (not (defined? 'FiguredBassActive))
    (begin
      (define FiguredBassActive #f)
      (define Figures "_")

        (define AddFigure (lambda (note bassnote)
                    (begin
                     ;; (display "adding a figure")
                     ;; (display Figures)
                      (set! Figures (cons  (d-BassFigure bassnote note) 
Figures)))))


(define GetFigures (lambda ()
                     (begin
                       (string-append "figures=" (string-join (reverse 
Figures))))))

(define loop  (lambda (bassnote)
                (let* ( 
                       (midi (d-GetMidi))
                       (velocity (bit-extract midi 16 24))
                       (note (bit-extract midi 8 16))
                       (command (bit-extract midi 0 8)))
                  ;; body of the let*
                   (begin
                   (if (= command #x90)
                       (begin
                         (if (and (> velocity 0)(= bassnote 0))
                             (begin 
                               (set! bassnote note)
                               (set! Figures '())
                               (d-PutMidi midi))
                             ;;; not bass note on 
                             (begin
                             (display "bass note was not on") 
                             (if (and (= velocity 0)(= note bassnote))
                                 (begin 
                                   (set! bassnote 0)
                                   (d-EditFiguredBass (GetFigures))
                                   (d-PutMidi midi))
                                 ;;; not bass note off
                                 (begin
                                   (if  (> velocity 0)
                                        (begin
                                          (AddFigure note bassnote)
                                          (d-PlayMidiKey midi)))))))))
                   (if (and (= command #xB0) (= note #x40) (= velocity #x7F))   
   
                       (begin
                         ;;(display "Pedal down")
                         (d-PlayMidiKey #xF01A01)
                         (set! Figures (cons " | "  Figures))))
                   (if  FiguredBassActive
                        (begin
                          (loop bassnote))))
)))));;; end of if not initialized

(set! FiguredBassActive (not FiguredBassActive))

(if FiguredBassActive
    (loop 0))


On Sun, 2008-11-23 at 17:21 +0000, Richard Shann wrote:
> On Sun, 2008-11-23 at 17:25 +0100, Nils Gey wrote:
> > Hi,
> > 
> > I lost a bit where Denemo stands now and what is work in progress.
> > 
> > Currently I see most work done on midi-import where two ways are 
> > implemented: 
> 
> > One JACK-midi and one direct access. 
> 
> > Maybe you can inform me (and others) why this dual system benefits the 
> > users?
> The direct access if for those (like my Debian Etch) that don't have
> jack-midi. I hope this can be dropped in the future.
> > 
> > Then all the time there are new scripts and functions which is really 
> > great. 
> 
> > Will these scripts be bundeld with new releases?
> I think we will put them all in the release, especially as we have no
> "More from Denemo.org" option (which I think the gio library makes
> possible).
> >  If Denemo gets more users and user scripts can we integrate a 
> 
> > system to easily download new scripts from the web in the (far away) 
> > future? 
> It is not the far-away future. I could have it done tomorrow, but it is
> not a high priority, as at the next release all the scripts available
> will be in the release itself. But as soon as releases become less
> frequent, and new scripts at Denemo.org become available we will want
> Denemo to have the "More from Denemo.org" option.
> 
> > Note: When the time comes where users actually want to submit scripts we 
> > (I) should be ready to give
> 
> >  them a central place to store them and also we should review 
> Yes: review will be important - you could easily write a scheme script
> to delete the user's home directory or some other malicious activity.
> > what scripts will show up so that we can include
> 
> >  the better ones right into the Denemo releases.
> 
> >  There a plentyful linux applications where the real deal is made with 
> > scripts (for example IRC clients
> 
> >  and where it is a pain to get the real good ones, integrate them to your 
> > software 
> 
> > and know any time which scripts work with the current version)
> Yes, there could be a lot of housekeeping needed.
> > 
> > What I see a bit ambivalent is that all these new features and scripts are 
> > not featured enough.
> 
> >  The "more commands" file browser
> There are two, for commands (actions) in the release (under
> $prefix/share/denemo/actions/menus
> and one for commands you have written yourself (under
> ~/.denemo/actions/menus).
> >  is a bit confusing because you have to scroll through your filesystem
> This is better than scrolling through a list of all commands: the
> filesystem is laid out to match the menu system, so that the menu names
> classify the commands.
> In the future we could run a script to list all the commands with
> tooltips and with parameters needed for calling from scheme, inserting
> this into the manual. 
> >  and you get not enough infos what these things are.
> In the future we would like the file selector to have an extra pane in
> which the tooltip of the selected command is displayed...
> Again, this is not rocket-science - on getting the selected signal you
> run the parser extract to tooltip and display it.
> 
> >  Especially when there will be more and more scripts this could be some 
> > issue for the users. A script-management dialog (like other programs have 
> > "plugin browsers") would be a great benefit. I'm just giving out ideas, I 
> > know there is much work to do which is more important. 
> > 
> > Did I forgot anything?
> > 
> > What is also a bit ambivalent (in my opinion) is that there are more and 
> > more features
> 
> >  which are just shown as little green lilypond-"lines". What is needed to 
> > make more functions "real" Denemo objects 
> I have a cleverer plan than that. Instead of making more and more "real"
> Denemo objects, (which involves creating more C-structures and writing C
> code to create/destroy/cut/paste/draw/store/load/print them,  we just
> make the lilypond objects more sophisticated. I have written about this
> earlier: I have also started implementing this, if you create a LilyPond
> directive you get ask for some display text. At the moment this text is
> just written somewhere with the little green line. (I think there may be
> a problem with the display of a newly-created insert? There is
> definitely a problem when you cut and paste them, they lose their
> display string then). I have these working for inserting repeat
> barlines. This is quite active.
> Eventually this can become some graphical sign, so that it looks like it
> should in real music.
> 
> > so that repeat bars, for example, are shown correctly? And how about 
> > scripts that add things to the lilypond-output, 
> 
> > is there a way that the scripter can distribute a graphic
> When we have the attaching of a graphic facility then, yes, we can let
> the user specify a .png, .svg or other to be used from
> d-InsertLilyDirective
> The scheme script would then say something like
> (d-InsertLilyDirective "lily=\\bar \":|\"\0graphic=
> \"CloseRepeatBarline.xbm\"\0x-offset=20\0y-offset=0")
> 
> where the x-offset, y-offsets would be saying where a repeat barline
> comes on the staff.
> >  with his script which could be added to the staffs? 
> > 
> > And last to that: How are icons done?
> It's all stock icons at the moment. It would require C-programming to
> add custom ones.
> >  Is there a way I can help with adding Icons for the menus? And can 
> > menu-commands which are script have their own icon, too? 
> Eventually... again it would require support in C.
> Richard
> 
> 
> 
> 
> _______________________________________________
> Denemo-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/denemo-devel