bend implementation

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bend implementation

Marc Hohl
I am planning to implement bends.

The more I think about it, Carls proposal to handle bends with some kind of
"auto beam" mechanism is a brilliant idea.

As I can see it now, there will be two new engravers necessary:
1) a pointed slur engraver which handles the normal staves
2) a bend arrow engraver for the tab staves

(for a more detailed description, please visit

http://lists.lilynet.net/tablatures/

and have a look at

tablature Feature Request Examples - Part 2)

As bends are somewhat "fundamental" actions which interact with e.g. the
TabNoteHead, I think that besides the possibility do create engravers in
scheme,
this should be done in c++, right?

I am not a very fast and skilled programmer, so I appreciate any kind
of help in this task. I am looking at the engraver sources, and while I
think
I begin to understand, I am still struggling with the fundamental concepts.

Greetings,

Marc

---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bend implementation

Carl Sorensen



On 1/11/10 3:41 AM, "Marc Hohl" <[hidden email]> wrote:

> I am planning to implement bends.
>
> The more I think about it, Carls proposal to handle bends with some kind of
> "auto beam" mechanism is a brilliant idea.

Wow, I haven't had a "brilliant" idea for years!  Thanks for the compliment.

>
> As I can see it now, there will be two new engravers necessary:
> 1) a pointed slur engraver which handles the normal staves
> 2) a bend arrow engraver for the tab staves

My initial thought was to have one engraver that would change its output
depending on the context in which it was placed.  That would avoid code
duplication.

But I could see doing it the other way as well.

>
> (for a more detailed description, please visit
>
> http://lists.lilynet.net/tablatures/
>
> and have a look at
>
> tablature Feature Request Examples - Part 2)
>
> As bends are somewhat "fundamental" actions which interact with e.g. the
> TabNoteHead, I think that besides the possibility do create engravers in
> scheme,
> this should be done in c++, right?

I'm not sure, because I've not really understood the capabilities of the
Scheme engravers.

If I were doing it, I'd do it in c++, because I want to have some static
variables in the engraver, and I don't know if I can do that in scheme.

>
> I am not a very fast and skilled programmer, so I appreciate any kind
> of help in this task. I am looking at the engraver sources, and while I
> think
> I begin to understand, I am still struggling with the fundamental concepts.
>

Me too, but I think I just learned something over the weekend when comparing
the fretboards engraver with the tab-note-head engraver.

An engraver needs to listen to events, and then it needs to process music.
When process music is called, all of the events at that time step should
have already been received.

This doesn't sound like much, but it was a key piece I was missing.

If you can ask some more specific questions, maybe we can get answers.

Look at some simple engravers (fretboards, chord-name) as well as some more
complicated engravers.  This might help you get a feel.

Thanks,

Carl


---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bend implementation

David Pounder
In reply to this post by Marc Hohl


>----Original Message----
>From: [hidden email]
>Date: 11/01/2010 14:55
>To: "Marc Hohl"<[hidden email]>, "[hidden email]"<frogs@lilynet.
net>
>Subj: Re: [frogs] bend implementation

>
>If I were doing it, I'd do it in c++, because I want to have some
static
>variables in the engraver, and I don't know if I can do that in
scheme.
>

It could be time-saving to at least prototype in Scheme and see if
anything crops up that really needs C++.

By static, do you mean having a variable maintain its state between
calls? If so it could be done as below:

\version "2.13.11"

#(define Engraver_with_static (list
  (cons 'process-music
    (let ((a 5))
      (lambda (x)
      (set! a (+ a 5))
      (display a)
      (newline)
  )))))

\layout {
  \context {
    \Voice
    \consists \Engraver_with_static
  }
}

\relative c' {
  c4 d e f
}

- David



2009: A year in review - http://www.tiscali.co.uk/2009


---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bend implementation

Neil Puttock
2010/1/11 [hidden email] <[hidden email]>:

> By static, do you mean having a variable maintain its state between
> calls? If so it could be done as below:

I guess Carl's thinking about variables which can be shared between
engraver functions, i.e., scheme analogues for the private members in
the C++ engravers which store events/grobs for later processing.
Since it's not possible to export bindings outside toplevel, I think
the only options are to use global defines or set context properties.

Regards,
Neil

---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bend implementation

Carl Sorensen



On 1/11/10 5:24 PM, "Neil Puttock" <[hidden email]> wrote:

> 2010/1/11 [hidden email] <[hidden email]>:
>
>> By static, do you mean having a variable maintain its state between
>> calls? If so it could be done as below:
>
> I guess Carl's thinking about variables which can be shared between
> engraver functions, i.e., scheme analogues for the private members in
> the C++ engravers which store events/grobs for later processing.

Yes, that's exactly what I mean.  We need to be able to have variables set
in listen and acted upon in process_music.

Thanks,

Carl


---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bend implementation

Marc Hohl
In reply to this post by Carl Sorensen
Carl Sorensen schrieb:

>
> On 1/11/10 3:41 AM, "Marc Hohl" <[hidden email]> wrote:
>
>  
>> I am planning to implement bends.
>>
>> The more I think about it, Carls proposal to handle bends with some kind of
>> "auto beam" mechanism is a brilliant idea.
>>    
>
> Wow, I haven't had a "brilliant" idea for years!  Thanks for the compliment.
>  
My approach was to use the left and right note and try to compute everything
correctly while somehow take care of everything happening before or after
the spanner, while you propose a more global structure which should be
able to
take care of everything more elegantly.

Moreover, I finally have some kind of starting point: I can try to
understand how engravers
work, especially the auto beam mechanism.

>  
>> As I can see it now, there will be two new engravers necessary:
>> 1) a pointed slur engraver which handles the normal staves
>> 2) a bend arrow engraver for the tab staves
>>    
>
> My initial thought was to have one engraver that would change its output
> depending on the context in which it was placed.  That would avoid code
> duplication.
>
> But I could see doing it the other way as well.
>  
When we can handle the whole story with one engraver, even better!

>  
>> (for a more detailed description, please visit
>>
>> http://lists.lilynet.net/tablatures/
>>
>> and have a look at
>>
>> tablature Feature Request Examples - Part 2)
>>
>> As bends are somewhat "fundamental" actions which interact with e.g. the
>> TabNoteHead, I think that besides the possibility do create engravers in
>> scheme,
>> this should be done in c++, right?
>>    
>
> I'm not sure, because I've not really understood the capabilities of the
> Scheme engravers.
>
> If I were doing it, I'd do it in c++, because I want to have some static
> variables in the engraver, and I don't know if I can do that in scheme.
>  
Ok, so I concentrate on this.

>  
>> I am not a very fast and skilled programmer, so I appreciate any kind
>> of help in this task. I am looking at the engraver sources, and while I
>> think
>> I begin to understand, I am still struggling with the fundamental concepts.
>>
>>    
>
> Me too, but I think I just learned something over the weekend when comparing
> the fretboards engraver with the tab-note-head engraver.
>
> An engraver needs to listen to events, and then it needs to process music.
> When process music is called, all of the events at that time step should
> have already been received.
>
> This doesn't sound like much, but it was a key piece I was missing.
>
> If you can ask some more specific questions, maybe we can get answers.
>
> Look at some simple engravers (fretboards, chord-name) as well as some more
> complicated engravers.  This might help you get a feel.
>  
Ok, I'll do.

Thank you

Marc


---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bend implementation

Carl Sorensen



On 1/13/10 1:23 AM, "Marc Hohl" <[hidden email]> wrote:

> Carl Sorensen schrieb:
>>
>> On 1/11/10 3:41 AM, "Marc Hohl" <[hidden email]> wrote:
>>
>>  
>>> I am planning to implement bends.
>>>
>>> The more I think about it, Carls proposal to handle bends with some kind of
>>> "auto beam" mechanism is a brilliant idea.
>>>    
>>
>> Wow, I haven't had a "brilliant" idea for years!  Thanks for the compliment.
>>  
> My approach was to use the left and right note and try to compute everything
> correctly while somehow take care of everything happening before or after
> the spanner, while you propose a more global structure which should be
> able to
> take care of everything more elegantly.
>
> Moreover, I finally have some kind of starting point: I can try to
> understand how engravers
> work, especially the auto beam mechanism.
>>  
>>> As I can see it now, there will be two new engravers necessary:
>>> 1) a pointed slur engraver which handles the normal staves
>>> 2) a bend arrow engraver for the tab staves
>>>    
>>
>> My initial thought was to have one engraver that would change its output
>> depending on the context in which it was placed.  That would avoid code
>> duplication.
>>
>> But I could see doing it the other way as well.
>>  
> When we can handle the whole story with one engraver, even better!

Well, we have a different engraver for note-heads and tab-note-heads
(because of the different position, I suppose), so it probably does make
more sense to have a bend-engraver and a tab-bend-engraver.

Thanks,

Carl


---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [frogs] bend implementation

Marc Hohl
In reply to this post by Carl Sorensen
Carl Sorensen schrieb:
> [...]
>
> If you can ask some more specific questions, maybe we can get answers.
>  
Ok, here is one:

I think I begin to understand how engravers work, but there are some issues
that  aren't perfectly clear.

With IMPLEMENT_TRANSLATOR_LISTENER
I tell the engraver which triggers it. The events are defined in
scm/define-music-events.scm, so I'll put some new events for triggering
bends there.

The whole ACKNOWLEDGER story is still a bit foggy to me.
What does that mean if I say

ADD_ACKNOWLEDGER (My_new_engraver, note_head); ?

Is this the key to get informations from the corresponding note heads
which I need to calculate the coordinates for the pointed slur?

The routines like ly:calc-pointed-slur-control-points don't belong
to the engraver, they are put in another file, isn't it? And there is no
master file which tells lilypond which *-engraver.cc files are
included, so if if roll my own engraver and do 'make all', it will be
present.

Thanks in advance,

Marc



---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [frogs] bend implementation

Marc Hohl
In reply to this post by Carl Sorensen
Carl Sorensen schrieb:
> [...]
>
> If you can ask some more specific questions, maybe we can get answers.
>  
Oh, here's a (probably) silly one:

By looking at glissando_engraver.cc or note_head_line_engraver.cc,
I don't see where the line is drawn. Where do I find these routines
that create the appropriate stencil?

Marc


---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [frogs] bend implementation

Trevor D-2
In reply to this post by Marc Hohl

Marc Hohl wrote Wednesday, January 20, 2010 10:11 AM

>
> I think I begin to understand how engravers work, but there are
> some issues
> that  aren't perfectly clear.
>
> With IMPLEMENT_TRANSLATOR_LISTENER
> I tell the engraver which triggers it. The events are defined in
> scm/define-music-events.scm, so I'll put some new events for
> triggering
> bends there.

Yes.  You need a DECLARE_TRANSLATOR_LISTENER
to declare several internal procedures relating
to the listened event.  It also declares the
  listen_<event> (Stream_event *)
method.  You will need to provide an implementation
of this to cache the events.

IMPLEMENT_TRANSLATOR_LISTENER implements the
methods declared by DECLARE_TRANSLATOR_LISTENER
and arranges for your listen_<event> method to
be called every time the required event is found
in the input stream.

> The whole ACKNOWLEDGER story is still a bit foggy to me.
> What does that mean if I say
>
> ADD_ACKNOWLEDGER (My_new_engraver, note_head); ?

ADD_ACKNOWLEDGER asks for your engraver to be
notified whenever the referenced grob is created.
It arranges for your acknowledge_<grobname> method
to be called when a grob with name <grob_name>
is created and passes a ref to it.  See any span
engraver, eg slur-engraver.cc for the details.

You can see the macro definitions in lily/translator.hh
and lil/translator.ihh.  These might help you to
understand what is going on behind the scenes.

> Is this the key to get informations from the corresponding note
> heads
> which I need to calculate the coordinates for the pointed slur?

I think so, but I don't know how.

> The routines like ly:calc-pointed-slur-control-points don't belong
> to the engraver, they are put in another file, isn't it? And there
> is no
> master file which tells lilypond which *-engraver.cc files are
> included, so if if roll my own engraver and do 'make all', it will
> be
> present.

Yes, if you call the correct macros it all happens
magically.  A separate file is used to contain any
routines which are (or might be) called from more
than one engraver.

Hope I've got that right!  I'm still learning too.

Trevor



---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [frogs] bend implementation

Carl Sorensen
In reply to this post by Marc Hohl



On 1/20/10 3:11 AM, "Marc Hohl" <[hidden email]> wrote:

> Carl Sorensen schrieb:
>> [...]
>>
>> If you can ask some more specific questions, maybe we can get answers.
>>  
> Ok, here is one:
>
> I think I begin to understand how engravers work, but there are some issues
> that  aren't perfectly clear.
>
> With IMPLEMENT_TRANSLATOR_LISTENER
> I tell the engraver which triggers it. The events are defined in
> scm/define-music-events.scm, so I'll put some new events for triggering
> bends there.

You should only need one new event, a string-bend event.  You would probably
also need to have a string-bend articulation, which would be used inside of
a chord.

string-bend should be a property of a note; you can have it be very similar
to a string definition.

>
> The whole ACKNOWLEDGER story is still a bit foggy to me.
> What does that mean if I say
>
> ADD_ACKNOWLEDGER (My_new_engraver, note_head); ?
>
> Is this the key to get informations from the corresponding note heads
> which I need to calculate the coordinates for the pointed slur?

An acknowledger is a piece of code that will be passed the event, and then
can be used to turn the event into a grob.  It's in the grob callback code,
rather than the acknowledgement code, that the coordinates will be
calculated.

As I understand it, engravers determine what grobs will be printed, and what
the properties of those grobs will be.  Engravers have finished their work
before the layout engine actually figures out where on the page the grobs
will be.

>
> The routines like ly:calc-pointed-slur-control-points don't belong
> to the engraver, they are put in another file, isn't it? And there is no
> master file which tells lilypond which *-engraver.cc files are
> included, so if if roll my own engraver and do 'make all', it will be
> present.

Yes, the .cc files are all compiled by their presence in the directory.

HTH,

Carl


---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [frogs] bend implementation

Carl Sorensen
In reply to this post by Marc Hohl



On 1/20/10 3:29 AM, "Marc Hohl" <[hidden email]> wrote:

> Carl Sorensen schrieb:
>> [...]
>>
>> If you can ask some more specific questions, maybe we can get answers.
>>  
> Oh, here's a (probably) silly one:
>
> By looking at glissando_engraver.cc or note_head_line_engraver.cc,
> I don't see where the line is drawn. Where do I find these routines
> that create the appropriate stencil?

Not silly at all.  This is a perfect engraver to get at the core confusing
LilyPond functionality.  The most confusing part is the seemingly immaculate
conversion from event to stencil (which happens by way of the grob).

Here is the line that creates the grob:
 line_ = make_spanner ("VoiceFollower", head_->self_scm ());

This creates a VoiceFollower grob.

From the internals reference, we see that the VoiceFollower grob has the
default stencil ly:line-spanner::print.  So the code that actually creates
the line is in ly:line-spanner::print.

You might have a BendIndicator grob, which will have its own stencil
routine.

HTH,

Carl


---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [frogs] bend implementation

Neil Puttock
In reply to this post by Trevor D-2
2010/1/20 Trevor Daniels <[hidden email]>:

> ADD_ACKNOWLEDGER asks for your engraver to be
> notified whenever the referenced grob is created.
> It arranges for your acknowledge_<grobname> method
> to be called when a grob with name <grob_name>
> is created and passes a ref to it.  See any span
> engraver, eg slur-engraver.cc for the details.

Slight misconception here (which I corrected recently in the CG): It's
the grob-interface which determines which grobs are acknowledged, not
the grob name.

Regards,
Neil

---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [frogs] bend implementation

Marc Hohl
Neil Puttock schrieb:

> 2010/1/20 Trevor Daniels <[hidden email]>:
>
>  
>> ADD_ACKNOWLEDGER asks for your engraver to be
>> notified whenever the referenced grob is created.
>> It arranges for your acknowledge_<grobname> method
>> to be called when a grob with name <grob_name>
>> is created and passes a ref to it.  See any span
>> engraver, eg slur-engraver.cc for the details.
>>    
>
> Slight misconception here (which I corrected recently in the CG): It's
> the grob-interface which determines which grobs are acknowledged, not
> the grob name.
>
> Regards,
> Neil
>
>  
Trevor, Carl and Neil,

thank you all for your informations - they are very helpful!
I will re-read some files now, and thereafter
a) start coding
b) ask more questions

I vote for a), but go for b) in the worst case ;-)

Thanks,

Marc

---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [frogs] bend implementation

Marc Hohl
In reply to this post by Carl Sorensen
Carl Sorensen schrieb:

>
> On 1/20/10 3:29 AM, "Marc Hohl" <[hidden email]> wrote:
>
>  
>> Carl Sorensen schrieb:
>>    
>>> [...]
>>>
>>> If you can ask some more specific questions, maybe we can get answers.
>>>  
>>>      
>> Oh, here's a (probably) silly one:
>>
>> By looking at glissando_engraver.cc or note_head_line_engraver.cc,
>> I don't see where the line is drawn. Where do I find these routines
>> that create the appropriate stencil?
>>    
>
> Not silly at all.  This is a perfect engraver to get at the core confusing
> LilyPond functionality.  The most confusing part is the seemingly immaculate
> conversion from event to stencil (which happens by way of the grob).
>
> Here is the line that creates the grob:
>  line_ = make_spanner ("VoiceFollower", head_->self_scm ());
>
> This creates a VoiceFollower grob.
>
> >From the internals reference, we see that the VoiceFollower grob has the
> default stencil ly:line-spanner::print.  So the code that actually creates
> the line is in ly:line-spanner::print.
>  
Ah, ok. I read tuplet-*.cc  where there are tons of stencil trickery,
and in glissando-engraver.cc, there's none.
As I have to draw sloping lines for the pointed slurs,  I thought that
the glissando offers some insight.
> You might have a BendIndicator grob, which will have its own stencil
> routine.
>  
Ok. I think it would not be a waste of time to sketch some kind of roadmap,
so your (and others') suggestions don't get lost.

Thanks,

Marc

> HTH,
>
> Carl
>
>
> ---
> ----
> Join the Frogs!
>
>
>  


---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [frogs] bend implementation

Carl Sorensen



On 1/21/10 12:21 AM, "Marc Hohl" <[hidden email]> wrote:

> Carl Sorensen schrieb:
>>
>> On 1/20/10 3:29 AM, "Marc Hohl" <[hidden email]> wrote:
>>
>>  
>>> Carl Sorensen schrieb:
>>>    
>>>> [...]
>>>>
>>>> If you can ask some more specific questions, maybe we can get answers.
>>>>
>>>>      
>>> Oh, here's a (probably) silly one:
>>>
>>> By looking at glissando_engraver.cc or note_head_line_engraver.cc,
>>> I don't see where the line is drawn. Where do I find these routines
>>> that create the appropriate stencil?
>>>    
>>
>> Not silly at all.  This is a perfect engraver to get at the core confusing
>> LilyPond functionality.  The most confusing part is the seemingly immaculate
>> conversion from event to stencil (which happens by way of the grob).
>>
>> Here is the line that creates the grob:
>>  line_ = make_spanner ("VoiceFollower", head_->self_scm ());
>>
>> This creates a VoiceFollower grob.
>>
>>> From the internals reference, we see that the VoiceFollower grob has the
>> default stencil ly:line-spanner::print.  So the code that actually creates
>> the line is in ly:line-spanner::print.
>>  
> Ah, ok. I read tuplet-*.cc  where there are tons of stencil trickery,
> and in glissando-engraver.cc, there's none.

In lily/tuplet-engraver.cc there is no stencil trickery.  There is a bit of
grob trickery in terms of deciding the columns the bracket should span.

Note that lily/tuplet-bracket.cc and lily/tuplet-number.cc create scheme
callbacks that will be used by the grob to create stencils.  They are not
part of the engraver, but are rather part of the output library.

Thanks for asking these questions.   They are helping to clarify my
understanding.

Carl


---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [frogs] bend implementation

Marc Hohl
In reply to this post by Marc Hohl
Marc Hohl schrieb:

> Neil Puttock schrieb:
>> 2010/1/20 Trevor Daniels <[hidden email]>:
>>
>>  
>>> ADD_ACKNOWLEDGER asks for your engraver to be
>>> notified whenever the referenced grob is created.
>>> It arranges for your acknowledge_<grobname> method
>>> to be called when a grob with name <grob_name>
>>> is created and passes a ref to it.  See any span
>>> engraver, eg slur-engraver.cc for the details.
>>>    
>>
>> Slight misconception here (which I corrected recently in the CG): It's
>> the grob-interface which determines which grobs are acknowledged, not
>> the grob name.
>>
>> Regards,
>> Neil
>>
>>  
> Trevor, Carl and Neil,
>
> thank you all for your informations - they are very helpful!
> I will re-read some files now, and thereafter
> a) start coding
> b) ask more questions
>
> I vote for a), but go for b) in the worst case ;-)
I will hopefully find the time to start with bend engravers soon, and I
am wondering
how to proceed. I think there will be more questions arising during the
work, mostly
silly ones (from a programmer's point of view), so I wonder whether I
should fill up the
frogs list with these questions, or does it make more sense to handle
this similar to
Graham's mentor proposals, so I fill up the mail inbox of just *one*
person ;-)

 From time to time, I can still mail a kind of summary of the work in
progress to the frogs
if this makes sense in order to provide some hints in engraver work for
the future.

What do you think?

Marc

>
> Thanks,
>
> Marc
>
> ---
> ----
> Join the Frogs!
>
>


---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [frogs] bend implementation

Andrew Wilson
On Tue, Jan 26, 2010 at 09:42:24AM +0100, Marc Hohl wrote:

> Marc Hohl schrieb:
>> Trevor, Carl and Neil,
>>
>> thank you all for your informations - they are very helpful!
>> I will re-read some files now, and thereafter
>>
>> a) start coding
>> b) ask more questions
>>
>> I vote for a), but go for b) in the worst case ;-)
>
> I will hopefully find the time to start with bend engravers soon, and I
> am wondering how to proceed. I think there will be more questions
> arising during the work, mostly silly ones (from a programmer's point of
> view), so I wonder whether I should fill up the frogs list with these
> questions, or does it make more sense to handle this similar to Graham's
> mentor proposals, so I fill up the mail inbox of just *one* person ;-)
>
> From time to time, I can still mail a kind of summary of the work in
> progress to the frogs if this makes sense in order to provide some hints
> in engraver work for the future.
>
> What do you think?

I think those kinds of discussions are what a frogs list is for, please
don't hide them away.  

andrew

---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [frogs] bend implementation

Carl Sorensen
In reply to this post by Marc Hohl
On 1/26/10 1:42 AM, "Marc Hohl" <[hidden email]> wrote:

> Marc Hohl schrieb:
>> Trevor, Carl and Neil,
>>
>> thank you all for your informations - they are very helpful!
>> I will re-read some files now, and thereafter
>> a) start coding
>> b) ask more questions
>>
>> I vote for a), but go for b) in the worst case ;-)
> I will hopefully find the time to start with bend engravers soon, and I
> am wondering
> how to proceed. I think there will be more questions arising during the
> work, mostly
> silly ones (from a programmer's point of view), so I wonder whether I
> should fill up the
> frogs list with these questions, or does it make more sense to handle
> this similar to
> Graham's mentor proposals, so I fill up the mail inbox of just *one*
> person ;-)
>
>  From time to time, I can still mail a kind of summary of the work in
> progress to the frogs
> if this makes sense in order to provide some hints in engraver work for
> the future.
>
> What do you think?

Please keep these questions on the Frogs list.  They will help lay a
foundation for working with engravers that will help lots of people.

And actually, please ask questions.  That will help us improve the CG.

Thanks,

Carl


---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [frogs] bend implementation

Trevor D-2
In reply to this post by Marc Hohl

Marc Hohl wrote Tuesday, January 26, 2010 8:42 AM
>
> I think there will be more questions arising during the work,
> mostly
> silly ones (from a programmer's point of view), so I wonder
> whether I should fill up the
> frogs list with these questions, or does it make more sense to
> handle this similar to
> Graham's mentor proposals, so I fill up the mail inbox of just
> *one* person ;-)

Far better to keep the discussion on the frogs list.  That way we
all learn and others are able to correct any misconceptions.  I've
learnt quite a lot thinking about questions posed on -frogs.

And please don't worry about asking questions you think might
be silly.  We all should be more willing to do this.  It's often the
silly questions that stump us the longest.

Trevor



---
----
Join the Frogs!

12
Loading...