jazzplusplus-devel — Discussion Forum for Jazz Developers

[jazzplusplus-devel] More selection stuff

[Dave F. <dav...@co...>]

All,

Ok, I went to implement selection finally, and hit another wall.  ;)  
Basically, it's the 'how' that's getting me.

I intend to implement it in a fashion that isn't dependent on the tracks 
appearing in any specific order, so that the GUI won't have to know how the 
project organizes the tracks and vice versa.  I figure the GUI needs to be 
able to layout the tracks in a more or less arbitrary fashion.  So here's the 
options as I see them:

1.  Each track has its own selection.  There would be methods such as 
"HasSelection" in tTrack, SetSelection, and ClearSelection (with SetSelection 
automatically calling ClearSelection), GetSelection, GetSelectedEvents, and 
so forth.  The main disadvantage here is that selection code will be spread 
out and jppProject will have to go through and clear every track when making 
a new selection.  The main advantage (and it's a big one) is that there would 
be a GetSelectedNotes method added to tTrack that would return a list of midi 
events contained in the selection.  The other methods require 
GetSelectedNotes(track) to be part of jppProject, which they arguably don't 
belong there.

2.  jppProject stores selection.  The big advantage here is that all the 
selection code will be kept in one place and tracks don't have to know about 
selection.  The disadvantages depend on implementation.  I figure there's two 
ways to implement this.

2a.  A list of tracks that are selected with a single Filter object storing 
the position/duration of the selection.  In this option, you'd have 
SetSelection in jppProject which would ClearSelection and set the 
position/duration of the select.  ClearSelection would clear all selection.  
AddSelection would add the selection to a track, so the GUI would have to 
iterate through all selected tracks saying "AddSelection(track)".

2b.  A list of tracks that are selected with position/duration as part of the 
list.  The main disadvantage here is that SetSelection would be 
SetSelection(track, beginning, ending) and the GUI would have to explicitly 
call ClearSelection every time a new selection is made.

3.  This is the most transparent and also the least.  :(  You pass a list to 
jppProject containing a track identifier (currently numbers), beginning and 
end of selection for each track to jppProject, and jppProject stores it 
however it wants (easiest to just copy the list to internal members to start, 
but could easily be changed later on).  Probably create a jppSelection class 
for this to manage the list.  SO the GUI would create a jppSelection 
instance, then SetSelectionPosition(start, end) and AddTrack(track 
identifier).  When it finishes making the list it would call 
jppProject->SetSelection(mySelectionObject) and jppProject would handle it 
from there.  It's the most transparent because the interface doesn't reflect 
how it's stored, but the least transparent because the GUI maybe shouldn't 
have to deal with a jppSelection object, it only needs to give start/end 
times and tracks.

Of the options I've come up with, I'm favoring 2a, which would provide the 
simplest interface, but not necessarily the easiest code to read.  It also 
doesn't provide complete transparency to selection to the GUI, but I think it 
would satisfy the needs, in any case.

I also intend to move the global Filter object into jppProject.  After 
selection is rewritten, I don't know if we'll need a global Filter object, 
but I can't justify getting rid of it completely.  Never know, and it might 
be a damn useful thing to have around anyway.  :)

What do you guys think?

On another note, I don't recall if I mentioned this or not, I made jppProject 
inherit from tSong.  So everywhere you call the global tSong should be 
changed to call the global gProject, and it should 'just work'.  That 
simplified making a track interface in the jppProject class without having to 
stupidly rewrite all the code to do it.  :)  We should be able to 
re-implement as needed to support whatever new backend we want for the thing, 
and ultimately get rid of tSong.  We may never need to get rid of tSong, 
though.  SO I didn't see a point to re-implementing the track interface, 
anyway, since my goal was to just put it in jppProject, not necessarily 
rewrite it.  ;)

Dave

-- 
Visit my website!
http://www.davefancella.com/?event=em

Sign my PETITION.

Re: [jazzplusplus-devel] some notes about flickering background in jazzpp

[joakim v. <jo...@ve...>]

Dave Fancella wrote:

>
>Assuming the space needed is larger than the window ever gets, can you just 
>draw the whole thing in your memory dc and then copy only the part that you 
>need for the window when you need it?  
>

Well thats basically the idea of double buffering combined with clipping.
Its not rocket science, but theres a lot of little details, like the 
translation
of coordinate spaces between scrolled and unscrolled areas. (sounds way 
harder than it is)

>Also, how does this affect selection?  
>I noticed some serious bugs in selection, and haven't managed to track them 
>down (it was hitting these bugs at the end of my last jazz timeslice that 
>stopped me from finishing the selection interface in the Project class).
>  
>
Which selection bugs are you talking about?

These are the ones I know about:

- The selection area doesnt follow the scroll area.
I believe this works at the moment.

- The selection doesnt draw very well.
This is because jazz sometimes uses a very lame screen update method.
It creates client dc:s in event handlers, and draws into them.

This is done with the selection and with the piano keys for instance.

This means screen updates are sometimes transient in jazz.

Its easier to explain how it *should* work:

- when you select a couple of events, these event should be marked as 
selected in
the "model". Then the gui should be redrawn with the selection state 
being taken
in consideration.

The effect would be more recognizeable as a standard ui paradigm as well.
A "rubber band" could be used for selection, and "selection state" could 
be indicated
with the events being drawn with thick borders or something.

So that would mean that as long as the model is updated properly, and 
the view drawing code is
correct, the views always represent the model properly. This maybe 
doesnt sound like much,
but currently it is impossible for the jazz gui to achieve this since it 
makes screen updates in
event handlers that are later forgotten.

Cheers,
/Joakim

Re: [jazzplusplus-devel] some notes about flickering background in jazzpp

[Dave F. <dav...@co...>]

On Sunday 11 April 2004 02:42 am, joakim verona wrote:
> - implementing the "erase" handler and also implementing "double buffering"
> seems achieve rock-solid redraw, but my implementation currently has
> other problems:
> a) you need a background bitmap to draw in, and I havent figured out how
> to know the right size for it yet
> b) events doesnt get drawn for some reason

Assuming the space needed is larger than the window ever gets, can you just 
draw the whole thing in your memory dc and then copy only the part that you 
need for the window when you need it?  Also, how does this affect selection?  
I noticed some serious bugs in selection, and haven't managed to track them 
down (it was hitting these bugs at the end of my last jazz timeslice that 
stopped me from finishing the selection interface in the Project class).

> Anyway, I think I'm on the right track, and we can at some future time
> have beautiful screen
> updates like Rosegarden :-P

Heh, you mean beautiful the RoseGarden's are beautiful, but you expect them to 
actually work, too, right?  ;)  (I spend more time swearing than composing 
when I use RoseGarden...)

Dave

-- 
Visit my website!
http://www.davefancella.com/?event=em

"What is wanted is not the will to believe, but the will to find out, which is
the exact opposite."
-- Bertrand Russell, _Sceptical_Essays_, 1928

[jazzplusplus-devel] some notes about flickering background in jazzpp

[joakim v. <jo...@ve...>]

Hello,

Here are some things I figured out about the background flicker that 
might or might not be news to you:

- Double buffering is easily achieved by the method Patrick suggested. 
(drawing to a temp dc and blitting)

- Sadly, this doesnt really help!

- Nowadays there is a "background erase event", that you can catch.
The default implementation of the event catcher should fill the 
background with grey.

Jazzpp fills the background with black however. I dont know why. This is 
why the flicker is so annoying,
at least for me.

- When I implement a dummy "bg erase" handler that does nothing, I get 
grey background erase,
which is much less annoying.

- implementing the "erase" handler and also implementing "double buffering"
seems achieve rock-solid redraw, but my implementation currently has 
other problems:
a) you need a background bitmap to draw in, and I havent figured out how 
to know the right size for it yet
b) events doesnt get drawn for some reason

Anyway, I think I'm on the right track, and we can at some future time 
have beautiful screen
updates like Rosegarden :-P


Cheers,
/Joakim

Re: [jazzplusplus-devel] Re: wx 2.5.1?

[joakim v. <jo...@ve...>]

Dave Fancella wrote:

>On Saturday 10 April 2004 04:32 am, joakim verona wrote:
>  
>
>>Anyway, a tidbit of information for you, there is a "no sequencer for
>>gtk availabel" on lad right now.
>>    
>>
>
>I'm sure there's a Qt/GTK flamewar in there somewhere about artistic ability 
>and competence...  If I were to add to the discussion, all I'd be able to add 
>is that all the Qt sequencers we do have are suffering from a combination of 
>feature creep and bug overload.  :(  I'm having a hard time believing 
>RoseGarden will ever be stable again.  Heh.
>
>So, any of them willing to come over and help?  ;)
>  
>
Well, since the thread has now escalated into flame-armageddon,
I thought I'd wait until the dust has settled a bit :-P

But I agree with you concerns. A sequencer doesnt necessarily
have to be lacking in features, but the features present should be 
sequencer features.

I cant find a sequencer with good scripting support for instance, which 
I really feel
would be very useful(like the csound people do for instance, building 
songs with python scripts)

This is a feature I would like to build using, for instance Swig, to 
generate wrappers around
the Jazzpp midi track classes to use within python, ruby, or whatever, 
scripts.

Cheers,
/Joakim

>Dave
>
>  
>

Re: [jazzplusplus-devel] Re: wx 2.5.1?

[Dave F. <dav...@co...>]

On Saturday 10 April 2004 04:32 am, joakim verona wrote:
> Anyway, a tidbit of information for you, there is a "no sequencer for
> gtk availabel" on lad right now.

I'm sure there's a Qt/GTK flamewar in there somewhere about artistic ability 
and competence...  If I were to add to the discussion, all I'd be able to add 
is that all the Qt sequencers we do have are suffering from a combination of 
feature creep and bug overload.  :(  I'm having a hard time believing 
RoseGarden will ever be stable again.  Heh.

So, any of them willing to come over and help?  ;)

Dave

-- 
Visit my website!
http://www.davefancella.com/?event=em

Yow!  Now we can become alcoholics!

[jazzplusplus-devel] Re: wx 2.5.1?

[joakim v. <jo...@ve...>]

Dave Fancella wrote:

>
>You might want to try breaking the window down into smaller widgets.  It might 
>work.  :)  I figure I'd like to see a separate widget for each track, and 
>then have a TrackPanel or something that arranges the tracks.  It's on my 
>list, of nobody gets to it first, but it's quite a ways down, and I'm not 
>exactly a graphics programmer.  :(
>
>  
>
I,ve been thinking along those lines too.
For example, the keyboard in the pianowin should be its own widget in 
its own pane.

The drawing of the main event area wont benefit from a split though, 
only double buffering will help.
This is because the flicker is caused by the graphics not being 
completely redrawn within a
vertical refresh cycle. At least thats what I think.


/Joakim

Re: [jazzplusplus-devel] Re: wx 2.5.1?

[joakim v. <jo...@ve...>]

Dave Fancella wrote:

>Well, in keeping in the spirit of calling for major upgrades to fix minor 
>problems...
>
>Why don't all you Swedes just speak English instead?
>  
>
Heh, that would be a downgrade :-P

But I agree with your point, wx 2.5 should not be a requirement at this 
point.

...and the availability of gtk 2 support in wx 2.4 nullifies my second 
point I guess.

hmmm.  I guess I'll go back to drawing dialogs then.

Anyway, a tidbit of information for you, there is a "no sequencer for 
gtk availabel" on lad right now.



/Joakim

>;)
>
>Jokes aside, wxGTK has had experimental GTK2 support for awhile, even in the 
>2.4 branch.  Are you using your own built wxGTK or RedHat's provided package?  
>The Mandrake package is compiled with GTK2 support, and I've loaded Audacity 
>up with other languages and slobbered over the beautiful fonts.  Makes me 
>wish I knew Russian or something, you know?  Such pretty letters....  And 
>then I couldn't quit the application because I don't know "Close" in Russian.  
>;)  (You *might* be able to install Mandrake's RPM on your RedHat system.  
>I've had it work successfully using RedHat packages on Mandrake, so if you 
>don't mind accidentally trashing your RPM database you could give it a shot)
>
>Anyway, you just:
>./configure --enable-gtk2
>I believe.  ./configure --help will show the option somewhere in there.  So if 
>you're using your own built wxGTK, I'd try recompiling it with GTK2 support 
>first and playing with localizing Jazz as it is.  That said, we will 
>eventually need to support wxGTK2.6.  But consider that to get the best 
>localization of Jazz we either have to tell users to compile wxGTK2.5 
>(experimental at best), or to compile wxGTK2.4 rather than use their 
>distro-provided package that's probably compiled against GTK1.2.
>
>Dave
>
>
>On Saturday 10 April 2004 01:29 am, joakim verona wrote:
>  
>
>>Yes, I was originally going to code it that way, I guess I should.
>>
>>(just a small note, when I first made the port this method wasnt
>>possible because
>>the OnPaint message didnt work, you could only derive the OnDraw method.
>>I changed the drawing to be based on the OnPaint message now, and it
>>seems to work)
>>
>>But there is another wx2.5 benefit.
>>
>>There is a gtk2 port for wx 2.5. This means
>>proper unicode support is possible.
>>
>>Gtk1.2 apps don't work very well with Swedish characters, which is my
>>native language.
>>The GTK1.2 apps in rh9 look very unimpressive in non english utf-8 locales,
>>for instance Audacity.
>>
>>So I'm going to give it a try to get it compiling in 2.5 without
>>breaking it in 2.4.
>>
>>We can use the wx version variable from configure to ifdef versions of
>>code.
>>
>>Cheers,
>>/Joakim
>>
>>Patrick Earl wrote:
>>    
>>
>>>On Thursday 08 April 2004 18:19, joakim verona wrote:
>>>      
>>>
>>>>I was wondering if anybody else was trying to compile jazz with wx
>>>>2.5.1.
>>>>
>>>>Im trying because I wanted to try to get rid of the anoying
>>>>redraw-flicker you get when scrolling a pianowin or  trackwin.
>>>>
>>>>In wx 2.5, there is a wxBufferedPaintDC that is supposed to fix the
>>>>redraw flicker.
>>>>        
>>>>
>>>I think it would solve the problem if we just draw to a memoryDC
>>>first, and then blit to the window when the paint event is requested.
>>>I believe the Buffered classes in 2.5 just make is slightly simpler
>>>to draw, but coding up one of those classes would be pretty easy as
>>>far as I can see.  You'd create a class that makes a wxMemoryDC in a
>>>constructor and writes to that.  Later, the destructor would blit the
>>>resulting bitmap to a wxClientDC.
>>>
>>>       Patrick
>>>      
>>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: IBM Linux Tutorials
>>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>>GenToo technologies. Learn everything from fundamentals to system
>>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>>_______________________________________________
>>jazzplusplus-devel mailing list
>>jaz...@li...
>>https://lists.sourceforge.net/lists/listinfo/jazzplusplus-devel
>>    
>>
>
>  
>

Re: [jazzplusplus-devel] Re: wx 2.5.1?

[Dave F. <dav...@co...>]

Well, in keeping in the spirit of calling for major upgrades to fix minor 
problems...

Why don't all you Swedes just speak English instead?

;)

Jokes aside, wxGTK has had experimental GTK2 support for awhile, even in the 
2.4 branch.  Are you using your own built wxGTK or RedHat's provided package?  
The Mandrake package is compiled with GTK2 support, and I've loaded Audacity 
up with other languages and slobbered over the beautiful fonts.  Makes me 
wish I knew Russian or something, you know?  Such pretty letters....  And 
then I couldn't quit the application because I don't know "Close" in Russian.  
;)  (You *might* be able to install Mandrake's RPM on your RedHat system.  
I've had it work successfully using RedHat packages on Mandrake, so if you 
don't mind accidentally trashing your RPM database you could give it a shot)

Anyway, you just:
./configure --enable-gtk2
I believe.  ./configure --help will show the option somewhere in there.  So if 
you're using your own built wxGTK, I'd try recompiling it with GTK2 support 
first and playing with localizing Jazz as it is.  That said, we will 
eventually need to support wxGTK2.6.  But consider that to get the best 
localization of Jazz we either have to tell users to compile wxGTK2.5 
(experimental at best), or to compile wxGTK2.4 rather than use their 
distro-provided package that's probably compiled against GTK1.2.

Dave


On Saturday 10 April 2004 01:29 am, joakim verona wrote:
> Yes, I was originally going to code it that way, I guess I should.
>
> (just a small note, when I first made the port this method wasnt
> possible because
> the OnPaint message didnt work, you could only derive the OnDraw method.
> I changed the drawing to be based on the OnPaint message now, and it
> seems to work)
>
> But there is another wx2.5 benefit.
>
> There is a gtk2 port for wx 2.5. This means
> proper unicode support is possible.
>
> Gtk1.2 apps don't work very well with Swedish characters, which is my
> native language.
> The GTK1.2 apps in rh9 look very unimpressive in non english utf-8 locales,
> for instance Audacity.
>
> So I'm going to give it a try to get it compiling in 2.5 without
> breaking it in 2.4.
>
> We can use the wx version variable from configure to ifdef versions of
> code.
>
> Cheers,
> /Joakim
>
> Patrick Earl wrote:
> >On Thursday 08 April 2004 18:19, joakim verona wrote:
> >>I was wondering if anybody else was trying to compile jazz with wx
> >>2.5.1.
> >>
> >>Im trying because I wanted to try to get rid of the anoying
> >>redraw-flicker you get when scrolling a pianowin or  trackwin.
> >>
> >>In wx 2.5, there is a wxBufferedPaintDC that is supposed to fix the
> >>redraw flicker.
> >
> >I think it would solve the problem if we just draw to a memoryDC
> >first, and then blit to the window when the paint event is requested.
> >I believe the Buffered classes in 2.5 just make is slightly simpler
> >to draw, but coding up one of those classes would be pretty easy as
> >far as I can see.  You'd create a class that makes a wxMemoryDC in a
> >constructor and writes to that.  Later, the destructor would blit the
> >resulting bitmap to a wxClientDC.
> >
> >        Patrick
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> jazzplusplus-devel mailing list
> jaz...@li...
> https://lists.sourceforge.net/lists/listinfo/jazzplusplus-devel

-- 
Visit my website!
http://www.davefancella.com/?event=em

There are many intelligent species in the universe, and they all own cats.

[jazzplusplus-devel] Re: wx 2.5.1?

[joakim v. <jo...@ve...>]

Yes, I was originally going to code it that way, I guess I should.

(just a small note, when I first made the port this method wasnt 
possible because
the OnPaint message didnt work, you could only derive the OnDraw method.
I changed the drawing to be based on the OnPaint message now, and it 
seems to work)

But there is another wx2.5 benefit.

There is a gtk2 port for wx 2.5. This means
proper unicode support is possible.

Gtk1.2 apps don't work very well with Swedish characters, which is my 
native language.
The GTK1.2 apps in rh9 look very unimpressive in non english utf-8 locales,
for instance Audacity.

So I'm going to give it a try to get it compiling in 2.5 without 
breaking it in 2.4.

We can use the wx version variable from configure to ifdef versions of code.

Cheers,
/Joakim




Patrick Earl wrote:

>On Thursday 08 April 2004 18:19, joakim verona wrote:
>  
>
>>I was wondering if anybody else was trying to compile jazz with wx
>>2.5.1.
>>
>>Im trying because I wanted to try to get rid of the anoying
>>redraw-flicker you get when scrolling a pianowin or  trackwin.
>>
>>In wx 2.5, there is a wxBufferedPaintDC that is supposed to fix the
>>redraw flicker.
>>    
>>
>
>I think it would solve the problem if we just draw to a memoryDC 
>first, and then blit to the window when the paint event is requested.  
>I believe the Buffered classes in 2.5 just make is slightly simpler 
>to draw, but coding up one of those classes would be pretty easy as 
>far as I can see.  You'd create a class that makes a wxMemoryDC in a 
>constructor and writes to that.  Later, the destructor would blit the 
>resulting bitmap to a wxClientDC.
>
>        Patrick
>  
>

[jazzplusplus-devel] Re: wx 2.5.1?

[Patrick E. <pa...@pa...>]

On Thursday 08 April 2004 18:19, joakim verona wrote:
> I was wondering if anybody else was trying to compile jazz with wx
> 2.5.1.
>
> Im trying because I wanted to try to get rid of the anoying
> redraw-flicker you get when scrolling a pianowin or  trackwin.
>
> In wx 2.5, there is a wxBufferedPaintDC that is supposed to fix the
> redraw flicker.

I think it would solve the problem if we just draw to a memoryDC 
first, and then blit to the window when the paint event is requested.  
I believe the Buffered classes in 2.5 just make is slightly simpler 
to draw, but coding up one of those classes would be pretty easy as 
far as I can see.  You'd create a class that makes a wxMemoryDC in a 
constructor and writes to that.  Later, the destructor would blit the 
resulting bitmap to a wxClientDC.

        Patrick

[jazzplusplus-devel] Re: wx 2.5.1?

[Dave F. <dav...@co...>]

On Thursday 08 April 2004 05:19 pm, joakim verona wrote:
> I was wondering if anybody else was trying to compile jazz with wx 2.5.1.
>
> Im trying because I wanted to try to get rid of the anoying redraw-flicker
> you get when scrolling a pianowin or  trackwin.
>
> In wx 2.5, there is a wxBufferedPaintDC that is supposed to fix the
> redraw flicker.

You might want to try breaking the window down into smaller widgets.  It might 
work.  :)  I figure I'd like to see a separate widget for each track, and 
then have a TrackPanel or something that arranges the tracks.  It's on my 
list, of nobody gets to it first, but it's quite a ways down, and I'm not 
exactly a graphics programmer.  :(

> jazz wont currently compile agains 2.5, and I think its because of the
> xrc stuff.

This is a good possibility, since the xrc that's in our source tree is from 
wx2.4, right?  You might want to go into configure.in and set it up to use a 
local xrc, if that's the problem.  Then you can compile the xrc that's in 
wx2.5's source tree instead of the one in ours.

I copied this back to the sourceforge mailing list.  ;)

Dave

-- 
Visit my website!
http://www.davefancella.com/?event=em

With a rubber duck, one's never alone.
		-- "The Hitchhiker's Guide to the Galaxy"

Re: [jazzplusplus-devel] Anybody home?

[Dave F. <dav...@co...>]

On Wednesday 07 April 2004 02:07 pm, Matt Kelly wrote:
> (tap tap tap) Is this thing on?
>
> Is it really this quiet, or is something broken with the list service?

Yeah, just quiet.  I'm in the last two weeks getting ready to take on the 
farmer's markets this summer.  I expect to have more time after that takes 
off.  :)  Just seems like an interesting coincidence that we all got covered 
with work at once.  Heh.  ;)

Dave

> Matt
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> jazzplusplus-devel mailing list
> jaz...@li...
> https://lists.sourceforge.net/lists/listinfo/jazzplusplus-devel

-- 
Visit my website!
http://www.davefancella.com/?event=em

About the only thing on a farm that has an easy time is the dog.

Re: [jazzplusplus-devel] Anybody home?

[Kevin C. <ke...@do...>]

On 7 April 2004 at 16:07, Matt Kelly <ra...@ch...> wrote:

> (tap tap tap) Is this thing on?
> 
> Is it really this quiet, or is something broken with the list service?

Nothing broken.  I'm still here.  I think others are likely too.

TTFN....

Re: [jazzplusplus-devel] Anybody home?

[Patrick E. <pa...@pa...>]

Looks on to me. :)  Been a little quiet though.  Myself, I'm working 
full time and finishing off the remnants of my thesis.  Once that's 
done, I'll have more time to code.

        Patrick

On Wednesday 07 April 2004 15:07, Matt Kelly wrote:
> (tap tap tap) Is this thing on?
>
> Is it really this quiet, or is something broken with the list
> service?
>
> Matt
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO
> of GenToo technologies. Learn everything from fundamentals to
> system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=cli
>ck _______________________________________________
> jazzplusplus-devel mailing list
> jaz...@li...
> https://lists.sourceforge.net/lists/listinfo/jazzplusplus-devel

[jazzplusplus-devel] Anybody home?

[Matt K. <ra...@ch...>]

(tap tap tap) Is this thing on?

Is it really this quiet, or is something broken with the list service?

Matt

[jazzplusplus-devel] many pianowin

[joakim v. <jo...@ve...>]

Hello,

I was playing with "hydrogen"(the drum sequencer) and thought that it 
would be nice
to allow a similar work model in jazzpp.

a drum sequncer normally has pattern mode and song mode.

The trackwin of jazz isnt really a song mode, but something else derived 
from
a multitrack recorder analogy.

If we wanted a song mode in jazz, it would be more like a new pianowin 
that could play
other tracks as patterns. Another pianowin can be used as a pattern editor.

Ok, that was pretty unclear so I'll try to be more concise:

- a drum machine song mode is a view of which patterns to play.
In jazz this is a pianowin thich shows "play track events".
I implemented this for jazz some time ago.

- a drum machine pattern view is in jazz a pianowin showing the details of
the track used with track play events.

To make this convenient/useful/fun you need a bit more work.

You also need it to be possible to open more pianowins than 1!
I did an experiment and checked it in.

There is now a "pianowin2" button that will open more pianowins.


/Joakim

Re: [jazzplusplus-devel] dynamic dialogs?

[joakim v. <jo...@ve...>]

Patrick Earl wrote:

>I was describing my idea of the client code.  Your idea of attaching 
>arrays is interesting, but how would you handle the case where there 
>are two areas within the dialog that have looped stuff added to them?  
>  
>
I would say that a) this case never happens with the current jazz dialogs,
and b) if we decide to build such dialogs it can be achieved with Daves 
idea.

/Joakim

>I'm not saying it's difficult... I just haven't thought about it.
>
>        Patrick
>
>On Friday 02 April 2004 13:25, joakim verona wrote:
>  
>
>>I'm not shure I'm following you entirely.
>>
>>The idea I had was that the loop that attaches holder variables
>>for one of the controllers in the panel copy we are attaching to
>>the parent dialog,  could reside within the jppResourceDialog,
>>rather than within the client code.
>>
>>For instance, with the mixer dialog as example, we have, say 6,
>>volume controllers,
>>and also 6 timbre controllers.
>>
>>So client code could look like this:
>>
>>long timbre[6];
>>long volume[6];
>>
>>jppResourcePanel panel("mixerpanel");
>>jppResourceDialog dialog("mixerparent", panel, 6, parentWin);
>>
>>dialog.AttachArray(timbre,"timbre");
>>dialog.AttachArray(timbre,"volume");
>>
>>
>>...which feels like a fairly compact description.
>>
>>(It seemed to me that it was the implementation of this you were
>>describing below.)
>>
>>
>>/Joakim
>>
>>Patrick Earl wrote:
>>    
>>
>>>On Friday 02 April 2004 00:49, Joakim Verona wrote:
>>>      
>>>
>>>>Yes, this seems very nice!
>>>>
>>>>How would the Attach function work in this case?
>>>>It would be neat if we could attach an array of values.
>>>>        
>>>>
>>>Is there much of an advantage to attaching an array?  In the case
>>>of my example, you could just stick the attach line in the
>>>example and assign it to a particular array index.  Are there
>>>cases where you wouldn't loop to add the extra widgets?  Or when
>>>the loop index probably wouldn't be numeric or sequentially
>>>numeric?
>>>
>>>        Patrick
>>>
>>>      
>>>
>>>>>jppResourceDialog dialog("myDialog", parentWin);
>>>>>for x in ["one", "two", "three"] {
>>>>>jppResoucePanel panel("myPanel");
>>>>>wxLabel *label = (wxLabel *) panel.FindWindowByName("myLabel");
>>>>>if(!label) cout << "You crazy!";
>>>>>label.SetText(x);
>>>>>dialog.AddToSizer("mySizer", panel);
>>>>>}
>>>>>          
>>>>>
>>>-------------------------------------------------------
>>>This SF.Net email is sponsored by: IBM Linux Tutorials
>>>Free Linux tutorial presented by Daniel Robbins, President and CEO
>>>of GenToo technologies. Learn everything from fundamentals to
>>>system
>>>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=c
>>>lick _______________________________________________
>>>jazzplusplus-devel mailing list
>>>jaz...@li...
>>>https://lists.sourceforge.net/lists/listinfo/jazzplusplus-devel
>>>      
>>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: IBM Linux Tutorials
>>Free Linux tutorial presented by Daniel Robbins, President and CEO
>>of GenToo technologies. Learn everything from fundamentals to
>>system
>>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=cli
>>ck _______________________________________________
>>jazzplusplus-devel mailing list
>>jaz...@li...
>>https://lists.sourceforge.net/lists/listinfo/jazzplusplus-devel
>>    
>>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>jazzplusplus-devel mailing list
>jaz...@li...
>https://lists.sourceforge.net/lists/listinfo/jazzplusplus-devel
>  
>

Re: [jazzplusplus-devel] dynamic dialogs?

[Dave F. <dav...@co...>]

On Saturday 03 April 2004 11:13 am, Patrick Earl wrote:
> I was describing my idea of the client code.  Your idea of attaching
> arrays is interesting, but how would you handle the case where there
> are two areas within the dialog that have looped stuff added to them?
> I'm not saying it's difficult... I just haven't thought about it.

Seems to me that you would do one of two things (possibly both?).  You'd 
create a new sizer in that area and just loop through the array adding new 
elements to the sizer accordingly, or you'd put a panel or some scrollable 
widget, then a sizer, and then loop the array adding new elements to the 
sizer.  The second option means it'll size with the dialog without forcing 
the dialog to be too big, possibly bigger than the screen.

So your dialog would have this sort of tree (better set to use a fixed font 
for this):

Dialog
   Panel
      Sizer
         SOme edit gadget
         Antoher edit gadget
         Scrollable widget   // This is the problem I'm solving here ;)
            Sizer
                First array element
                Second array element
         Yet another widget

Dave

>         Patrick
>
> On Friday 02 April 2004 13:25, joakim verona wrote:
> > I'm not shure I'm following you entirely.
> >
> > The idea I had was that the loop that attaches holder variables
> > for one of the controllers in the panel copy we are attaching to
> > the parent dialog,  could reside within the jppResourceDialog,
> > rather than within the client code.
> >
> > For instance, with the mixer dialog as example, we have, say 6,
> > volume controllers,
> > and also 6 timbre controllers.
> >
> > So client code could look like this:
> >
> > long timbre[6];
> > long volume[6];
> >
> > jppResourcePanel panel("mixerpanel");
> > jppResourceDialog dialog("mixerparent", panel, 6, parentWin);
> >
> > dialog.AttachArray(timbre,"timbre");
> > dialog.AttachArray(timbre,"volume");
> >
> >
> > ...which feels like a fairly compact description.
> >
> > (It seemed to me that it was the implementation of this you were
> > describing below.)
> >
> >
> > /Joakim
> >
> > Patrick Earl wrote:
> > >On Friday 02 April 2004 00:49, Joakim Verona wrote:
> > >>Yes, this seems very nice!
> > >>
> > >>How would the Attach function work in this case?
> > >>It would be neat if we could attach an array of values.
> > >
> > >Is there much of an advantage to attaching an array?  In the case
> > > of my example, you could just stick the attach line in the
> > > example and assign it to a particular array index.  Are there
> > > cases where you wouldn't loop to add the extra widgets?  Or when
> > > the loop index probably wouldn't be numeric or sequentially
> > > numeric?
> > >
> > >         Patrick
> > >
> > >>>jppResourceDialog dialog("myDialog", parentWin);
> > >>>for x in ["one", "two", "three"] {
> > >>> jppResoucePanel panel("myPanel");
> > >>> wxLabel *label = (wxLabel *) panel.FindWindowByName("myLabel");
> > >>> if(!label) cout << "You crazy!";
> > >>> label.SetText(x);
> > >>> dialog.AddToSizer("mySizer", panel);
> > >>>}
> > >
> > >-------------------------------------------------------
> > >This SF.Net email is sponsored by: IBM Linux Tutorials
> > >Free Linux tutorial presented by Daniel Robbins, President and CEO
> > > of GenToo technologies. Learn everything from fundamentals to
> > > system
> > > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=c
> > >lick _______________________________________________
> > >jazzplusplus-devel mailing list
> > >jaz...@li...
> > >https://lists.sourceforge.net/lists/listinfo/jazzplusplus-devel
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President and CEO
> > of GenToo technologies. Learn everything from fundamentals to
> > system
> > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=cli
> >ck _______________________________________________
> > jazzplusplus-devel mailing list
> > jaz...@li...
> > https://lists.sourceforge.net/lists/listinfo/jazzplusplus-devel
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> jazzplusplus-devel mailing list
> jaz...@li...
> https://lists.sourceforge.net/lists/listinfo/jazzplusplus-devel

-- 
Visit my website!
http://www.davefancella.com/?event=em

What is a magician but a practising theorist?
		-- Obi-Wan Kenobi

Re: [jazzplusplus-devel] dynamic dialogs?

[Patrick E. <pa...@pa...>]

I was describing my idea of the client code.  Your idea of attaching 
arrays is interesting, but how would you handle the case where there 
are two areas within the dialog that have looped stuff added to them?  
I'm not saying it's difficult... I just haven't thought about it.

        Patrick

On Friday 02 April 2004 13:25, joakim verona wrote:
> I'm not shure I'm following you entirely.
>
> The idea I had was that the loop that attaches holder variables
> for one of the controllers in the panel copy we are attaching to
> the parent dialog,  could reside within the jppResourceDialog,
> rather than within the client code.
>
> For instance, with the mixer dialog as example, we have, say 6,
> volume controllers,
> and also 6 timbre controllers.
>
> So client code could look like this:
>
> long timbre[6];
> long volume[6];
>
> jppResourcePanel panel("mixerpanel");
> jppResourceDialog dialog("mixerparent", panel, 6, parentWin);
>
> dialog.AttachArray(timbre,"timbre");
> dialog.AttachArray(timbre,"volume");
>
>
> ...which feels like a fairly compact description.
>
> (It seemed to me that it was the implementation of this you were
> describing below.)
>
>
> /Joakim
>
> Patrick Earl wrote:
> >On Friday 02 April 2004 00:49, Joakim Verona wrote:
> >>Yes, this seems very nice!
> >>
> >>How would the Attach function work in this case?
> >>It would be neat if we could attach an array of values.
> >
> >Is there much of an advantage to attaching an array?  In the case
> > of my example, you could just stick the attach line in the
> > example and assign it to a particular array index.  Are there
> > cases where you wouldn't loop to add the extra widgets?  Or when
> > the loop index probably wouldn't be numeric or sequentially
> > numeric?
> >
> >         Patrick
> >
> >>>jppResourceDialog dialog("myDialog", parentWin);
> >>>for x in ["one", "two", "three"] {
> >>> jppResoucePanel panel("myPanel");
> >>> wxLabel *label = (wxLabel *) panel.FindWindowByName("myLabel");
> >>> if(!label) cout << "You crazy!";
> >>> label.SetText(x);
> >>> dialog.AddToSizer("mySizer", panel);
> >>>}
> >
> >-------------------------------------------------------
> >This SF.Net email is sponsored by: IBM Linux Tutorials
> >Free Linux tutorial presented by Daniel Robbins, President and CEO
> > of GenToo technologies. Learn everything from fundamentals to
> > system
> > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=c
> >lick _______________________________________________
> >jazzplusplus-devel mailing list
> >jaz...@li...
> >https://lists.sourceforge.net/lists/listinfo/jazzplusplus-devel
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO
> of GenToo technologies. Learn everything from fundamentals to
> system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=cli
>ck _______________________________________________
> jazzplusplus-devel mailing list
> jaz...@li...
> https://lists.sourceforge.net/lists/listinfo/jazzplusplus-devel

Re: [jazzplusplus-devel] dynamic dialogs?

[joakim v. <jo...@ve...>]

I'm not shure I'm following you entirely.

The idea I had was that the loop that attaches holder variables
for one of the controllers in the panel copy we are attaching to
the parent dialog,  could reside within the jppResourceDialog, rather than
within the client code.

For instance, with the mixer dialog as example, we have, say 6, volume 
controllers,
and also 6 timbre controllers.

So client code could look like this:

long timbre[6];
long volume[6];

jppResourcePanel panel("mixerpanel");
jppResourceDialog dialog("mixerparent", panel, 6, parentWin);

dialog.AttachArray(timbre,"timbre");
dialog.AttachArray(timbre,"volume");


...which feels like a fairly compact description.

(It seemed to me that it was the implementation of this you were 
describing below.)


/Joakim



Patrick Earl wrote:

>On Friday 02 April 2004 00:49, Joakim Verona wrote:
>  
>
>>Yes, this seems very nice!
>>
>>How would the Attach function work in this case?
>>It would be neat if we could attach an array of values.
>>    
>>
>
>Is there much of an advantage to attaching an array?  In the case of 
>my example, you could just stick the attach line in the example and 
>assign it to a particular array index.  Are there cases where you 
>wouldn't loop to add the extra widgets?  Or when the loop index 
>probably wouldn't be numeric or sequentially numeric?
>
>         Patrick
>
>  
>
>>>jppResourceDialog dialog("myDialog", parentWin);
>>>for x in ["one", "two", "three"] {
>>> jppResoucePanel panel("myPanel");
>>> wxLabel *label = (wxLabel *) panel.FindWindowByName("myLabel");
>>> if(!label) cout << "You crazy!";
>>> label.SetText(x);
>>> dialog.AddToSizer("mySizer", panel);
>>>}
>>>      
>>>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>jazzplusplus-devel mailing list
>jaz...@li...
>https://lists.sourceforge.net/lists/listinfo/jazzplusplus-devel
>  
>

Re: [jazzplusplus-devel] dynamic dialogs?

[Patrick E. <pa...@pa...>]

On Friday 02 April 2004 00:49, Joakim Verona wrote:
> Yes, this seems very nice!
>
> How would the Attach function work in this case?
> It would be neat if we could attach an array of values.

Is there much of an advantage to attaching an array?  In the case of 
my example, you could just stick the attach line in the example and 
assign it to a particular array index.  Are there cases where you 
wouldn't loop to add the extra widgets?  Or when the loop index 
probably wouldn't be numeric or sequentially numeric?

         Patrick

> >jppResourceDialog dialog("myDialog", parentWin);
> >for x in ["one", "two", "three"] {
> >  jppResoucePanel panel("myPanel");
> >  wxLabel *label = (wxLabel *) panel.FindWindowByName("myLabel");
> >  if(!label) cout << "You crazy!";
> >  label.SetText(x);
> >  dialog.AddToSizer("mySizer", panel);
> >}

Re: [jazzplusplus-devel] dynamic dialogs?

[Joakim V. <jo...@ve...>]

Yes, this seems very nice!

How would the Attach function work in this case?
It would be neat if we could attach an array of values.

/Joakim


Patrick Earl wrote:

>On Thursday 01 April 2004 00:42, Joakim Verona wrote:
>  
>
>>The later aproach could maybe be achieved with 2 resources, one for
>>the dialog, and one used as a template for dynamic addition to the
>>parent dialog.
>>    
>>
>
>That's a cool idea.  I'm implementing something right now, I think it 
>will work out well.  I don't have time to finish it tonight, but I'll 
>describe the basic idea.
>
>I've created a new class called jppResourcePanel.  You construct it by 
>passing it a name and it will load the named panel from one of the 
>same files you did a jppResourceDialog::LoadResource() on.
>
>Once you have the panel, there's a method that's used to add it to an 
>existing dialog, namely to a sizer within the dialog.  It would work 
>something like this, minus the pythonish for loop:
>
>jppResourceDialog dialog("myDialog", parentWin);
>for x in ["one", "two", "three"] {
>  jppResoucePanel panel("myPanel");
>  wxLabel *label = (wxLabel *) panel.FindWindowByName("myLabel");
>  if(!label) cout << "You crazy!";
>  label.SetText(x);
>  dialog.AddToSizer("mySizer", panel);
>}
>
>I haven't though through the memory management yet, so that may be 
>something like panel = new jppResourcePanel("myPanel").  In any case, 
>it's nearly as simple.  Does that look good?  Are there improvements 
>to be made?
>
>Okay, time for bed.
>
>        Patrick
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>jazzplusplus-devel mailing list
>jaz...@li...
>https://lists.sourceforge.net/lists/listinfo/jazzplusplus-devel
>  
>

Re: [jazzplusplus-devel] dynamic dialogs?

[Patrick E. <pa...@pa...>]

On Thursday 01 April 2004 00:42, Joakim Verona wrote:
> The later aproach could maybe be achieved with 2 resources, one for
> the dialog, and one used as a template for dynamic addition to the
> parent dialog.

That's a cool idea.  I'm implementing something right now, I think it 
will work out well.  I don't have time to finish it tonight, but I'll 
describe the basic idea.

I've created a new class called jppResourcePanel.  You construct it by 
passing it a name and it will load the named panel from one of the 
same files you did a jppResourceDialog::LoadResource() on.

Once you have the panel, there's a method that's used to add it to an 
existing dialog, namely to a sizer within the dialog.  It would work 
something like this, minus the pythonish for loop:

jppResourceDialog dialog("myDialog", parentWin);
for x in ["one", "two", "three"] {
  jppResoucePanel panel("myPanel");
  wxLabel *label = (wxLabel *) panel.FindWindowByName("myLabel");
  if(!label) cout << "You crazy!";
  label.SetText(x);
  dialog.AddToSizer("mySizer", panel);
}

I haven't though through the memory management yet, so that may be 
something like panel = new jppResourcePanel("myPanel").  In any case, 
it's nearly as simple.  Does that look good?  Are there improvements 
to be made?

Okay, time for bed.

        Patrick

Re: [jazzplusplus-devel] i18n?

[Patrick E. <pa...@pa...>]

On Thursday 01 April 2004 03:05, Dave Fancella wrote:
> On Thursday 01 April 2004 06:00 pm, joakim verona wrote:
> > How does i18n work in wxWidgets?
>
> http://www.wxwidgets.org/manuals/2.4.2/wx460.htm#internationalizati
>on
>
> Not sure how this affects xrc.

I'm suspect it doesn't help with XRC, but the cool thing is that it 
doesn't matter so much.  It would be pretty easy to parse the XML and 
replace all the strings in the dialogs.  If the dialogs are 
problematic in terms of length of text or something, they could be 
translated by hand.  Since the XRC files are all loaded at runtime, 
it would simply mean using a different set of resources.

        Patrick