jazzplusplus-devel — Discussion Forum for Jazz Developers

Re: [jazzplusplus-devel] more dialog implementation queries

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

On Friday 26 March 2004 10:14 am, Joakim Verona wrote:
> Dave Fancella wrote:
> >I strongly suggest checking out the sliders in Audacity.  They're real
> > nice, have tooltips already to show the values stored, and are capable of
> > displaying several different units of volume.  They're both easy and hard
> > to use, though.  :(
>
> Which gui toolkit does audacity use?

wxWidgets.  :)  Attached are the ASlider class files, and I'll poke around 
real quick and see if there are any other files that should be here.

Dave

> Cheers,
> /Joakim
>
>
>
>
> -------------------------------------------------------
> 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

Last week's pet, this week's special.

Re: [jazzplusplus-devel] It's a night. Reduced trackwin's global variable dependence

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

On Friday 26 March 2004 09:47 am, Joakim Verona wrote:
> >Ultimately I'd like to have Jazz using its own project file format and
> > reading midi files will be done by importing the file.  There are bad
> > reasons to do this, and good ones.  Mainly I want to be able to embed wav
> > data in a project file, and have a good open project file format that
> > will allow easily adding patterns, templates, and stuff, and easily
> > support multiple midi devices in the studio (similar to RoseGarden, in
> > fact as a proof-of-concept when we get there, someone (me?) should write
> > an importer for RoseGarden projects).
>
> Yes, Jazz would need its own format at some point.
>
> Something I did with Jazz was to add the facility to play tracks from
> other tracks,
> a playtrack event. This was a feature in a sorely-missed amiga sequencer
> I used, Music-X.

Heh, never used Music-X.  MeD was a lot of fun, though.  ;)  (DMCS also had an 
unbeated staff editor, the likes of which I haven't seen again but has 
probably been bested)

> This doesnt entirely fit with the normal midi-file standard(although
> there are sequence play midi events),
> so i kind of kludged it in in Jazz midi format :-P
>
> Anyway, these kind of features would be easier with a new format.
>
> I would advocate looking at existing formats before inventing something,
> like
> music-xml or something(music-xml has taken some flak, but it can't be
> all bad can it?)

Actually, the specific format I was interested in is adapting Audacity's 
project format.  Audacity, being a sound editor, has serious problems dealing 
with memory and the raw amount of data it processes.  But they've solved a 
number of problems relevant here, like having unlimited undo across saves.  
Anyway, we don't have the same memory problems with midi, since a midi file 
is small enough that we can probably put a hundred in memory at one time.  
Anyway, I want to adapt their blockfile approach.

So, Audacity has a data directory for the project, and a project file.  The 
project file is xml and it tells what order the files in the data directory 
go in, what tracks they belong to, and so forth.  I think the project file 
also stores the history queue.

So, what I want to do with Jazz is store blocks of midi data in midi files, 
one track to a file, and organized in blocks of data.  We don't need this for 
the RAM, but it would be useful for pattern support and unlimited undo.  I 
want to use their exact project file format, extended to support midi 
blockfiles, and derive from their BlockFile class to create midi support.

It has the disadvantage of having the project spread out into a bunch of small 
files.  We can optimize for that, since midi files are so small we can still 
load the whole project into memory, and just clear out memory when something 
gets pushed to the history queue.  There might be other ways to approach the 
problem of having all these files strewn about a directory hierarchy, but I 
think the advantages far outweigh the disadvantages and am fully prepared to 
defend this idea.  :)

Dave

> An xml based aproach would open up for many cool concepts, like using
> XSLT transforms
> for midi event processing, which could be re-used in other projects.
>
> One of my ideas for Jazz is to open up for plugins and so on that
> manipulates event data,
> like GIMP:s python, scheme, and perl interfaces.
>
>
> Cheers,
> Joakim
>
> >Dave
>
> -------------------------------------------------------
> 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

You now have Asian Flu.

Re: [jazzplusplus-devel] more dialog implementation queries

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

Dave Fancella wrote:

>
>I strongly suggest checking out the sliders in Audacity.  They're real nice, 
>have tooltips already to show the values stored, and are capable of 
>displaying several different units of volume.  They're both easy and hard to 
>use, though.  :(
>
>  
>

Which gui toolkit does audacity use?

Cheers,
/Joakim

Re: [jazzplusplus-devel] more dialog implementation queries

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

Patrick Earl wrote:

>On Thursday 25 March 2004 13:49, joakim verona wrote:
>  
>
>>  dialog.Attach("scale", &scale);
>>  dialog.Attach("clockDelay", &clockDelay);
>>  dialog.Attach("repeat", &repeat);
>>    
>>
>
>I implemented int* versions of the Attach methods.  I also added 
>support for wxSlider.  I didn't test any the recent changes, so it 
>may not work.  I really need to head to bed.
>  
>
cool.

>Another possibility is adding Attach methods like this:
>
>    Attach(wxString name, double *ptr, double divisor);
>
>When the values come out of the slider it automatically performs the 
>division for you.  The sliders could be phrased in terms of percent 
>or something like that.  The XRC resource controls the range and 
>labels on the slider.
>
>Another possibility would be implementing our own double capable 
>sliders. Probably wouldn't be too hard, but not a trivial task 
>either.
>  
>
Well, there are a couple of "double" capable controls in the jazz gui,
so we should figure out something to use at all such places.

What would be useful is a combination of string entry box and
a slider(or knob).

Is it difficult to create your own widget in wxwidgets?

or do I just subclass and instantiate 2 components within + glue logic,
and voila new component like in "Swing"(or whatever modern toolkit)?

How would the new component interface with wxwidgets gui builders like
xrced or wxDesigner?

Cheers,
Joakim

>        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] It's a night. Reduced trackwin's global variable dependence

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

>Ultimately I'd like to have Jazz using its own project file format and reading 
>midi files will be done by importing the file.  There are bad reasons to do 
>this, and good ones.  Mainly I want to be able to embed wav data in a project 
>file, and have a good open project file format that will allow easily adding 
>patterns, templates, and stuff, and easily support multiple midi devices in 
>the studio (similar to RoseGarden, in fact as a proof-of-concept when we get 
>there, someone (me?) should write an importer for RoseGarden projects).
>  
>
Yes, Jazz would need its own format at some point.

Something I did with Jazz was to add the facility to play tracks from 
other tracks,
a playtrack event. This was a feature in a sorely-missed amiga sequencer 
I used, Music-X.

This doesnt entirely fit with the normal midi-file standard(although 
there are sequence play midi events),
so i kind of kludged it in in Jazz midi format :-P

Anyway, these kind of features would be easier with a new format.

I would advocate looking at existing formats before inventing something, 
like
music-xml or something(music-xml has taken some flak, but it can't be 
all bad can it?)

An xml based aproach would open up for many cool concepts, like using 
XSLT transforms
for midi event processing, which could be re-used in other projects.

One of my ideas for Jazz is to open up for plugins and so on that 
manipulates event data,
like GIMP:s python, scheme, and perl interfaces.


Cheers,
Joakim

>Dave
>
>  
>

[jazzplusplus-devel] It's a night. Reduced trackwin's global variable dependence

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

All,

Working on that middle layer.  :)  I reduced some of trackwin's dependence on 
global variables tonight, but it ain't pretty.  Tomorrow I'll tackle handling 
selection, which should make it possible to clean up everything I did 
tonight.  :)  Mostly I changed a lot of calls to separate global variables to 
calls within gProject.  It's not quite the nice API I'm trying to build yet, 
though.  I might have to implement a track interface at that time, which will 
be good to get rid of the tSong class.

I hope I didn't break anything with this commit, but I probably did.  :(  It 
still builds, though.  :)

Anyway, on handling selection.  Here's what I'm shooting for and the steps I'm 
planning on taking to get there.

I'm shooting to have a jppTrack class that stores track data for each track in 
the song and eliminating the tSong class with it.  Most of tSong will get 
factored into jppProject and jppTrack.  Anyway, I want jppTrack to store 
selection data, and I want some GUI widget to share a pointer (probably use 
reference counting) to the internal jppTrack that both jppProject and the 
mysterious GUI widget know about.  I want trackwin to dynamically create a 
new GUI track for each track in the project, and allow for creating new 
tracks.  So I want each jppTrack to store its own selection data.  :)

So, I figure I'll make an interface to selection data in jppProject as a 
stepping-stone, and I'll switch trackwin to use that.  That will allow me to 
later work on the jppTrack class and rewrite the selection implementation in 
jppProject to use the new jppTrack when it's ready.  I'll also change the 
Open and Save methods (now stored in jppProject) to create new jppTracks 
instead of sticking it in a song.  I figure the existing GUI will just ask 
jppProject what's selected in order to draw it, and when the user makes a new 
selection it will tell jppProject about the new selection.  Ultimately I want 
the GUI to be able to ask the tracks themselves for selection data, so having 
a selection interface in jppProject is just a steppingstone and will become 
deprecated as soon as there's a jppTrack class.  :)

The main thing about selection is that there's a lot of middle-layer logic in 
tTrackWin::MousePlay that uses selection data to figure out where to start 
playing, what to record, and so forth.  I consider selection to be data 
shared between the middle layer and the GUI layer, so I figure I'll move it 
to the middle layer and give the GUI strong access to it (like having its own 
pointer and using reference counting or some method like that).

Eliminating the tSong class and the corresponding Song global variable is 
going to affect pretty much everything, near as I can tell.  That's ok, 
though.  :)  If you want to work on eliminating the Song global variable, you 
can add your 'extern gProject' line to any file currently using the Song 
variable and change every reference to Song to gProject->Song.  That, at 
least, brings all the global variables into one place.  It won't help to 
eliminate the class, though.  What's needed is an interface in gProject to 
the tracks themselves that's independent of the backend storage facility, and 
the tSong class turned into the backend storage facility.  So jppProject 
would be a light layer between the GUI and tSong, but that interface to the 
tracks themselves is needed to be able to make the change in the backend 
storage facility.

Ultimately I'd like to have Jazz using its own project file format and reading 
midi files will be done by importing the file.  There are bad reasons to do 
this, and good ones.  Mainly I want to be able to embed wav data in a project 
file, and have a good open project file format that will allow easily adding 
patterns, templates, and stuff, and easily support multiple midi devices in 
the studio (similar to RoseGarden, in fact as a proof-of-concept when we get 
there, someone (me?) should write an importer for RoseGarden projects).

Dave

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

A fool's brain digests philosophy into folly, science into superstition, and
art into pedantry.  Hence University education.
		-- G. B. Shaw

Re: [jazzplusplus-devel] more dialog implementation queries

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

On Thursday 25 March 2004 13:49, joakim verona wrote:
>   dialog.Attach("scale", &scale);
>   dialog.Attach("clockDelay", &clockDelay);
>   dialog.Attach("repeat", &repeat);

I implemented int* versions of the Attach methods.  I also added 
support for wxSlider.  I didn't test any the recent changes, so it 
may not work.  I really need to head to bed.

> It fails, because there are only long* prototypes of Attach.
> Is this so by design or because floats havent been implemented?
>
> I suspect it's by design, because I couldnt find a "double" capable
> slider either.
>
> I could of course use longs in the gui, and convert to double when
> sending to the command object.

Another possibility is adding Attach methods like this:

    Attach(wxString name, double *ptr, double divisor);

When the values come out of the slider it automatically performs the 
division for you.  The sliders could be phrased in terms of percent 
or something like that.  The XRC resource controls the range and 
labels on the slider.

Another possibility would be implementing our own double capable 
sliders. Probably wouldn't be too hard, but not a trivial task 
either.

        Patrick

Re: [jazzplusplus-devel] Memory leak

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

On Thursday 25 March 2004 01:24 am, Dave Fancella wrote:
> I think I just committed a memory leak.  Sorry!  I created the gProject
> object in OnInit(), but I must admit I'm not certain where to destroy it.
>
> :(

Fixed now.  :)  I created tApp::OnExit(), which is called after all the wx GUI 
controls and stuff are destroyed but before library cleanup and deleted 
gProject there.  :)

Dave

> Dave

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

In this world some people are going to like me and some are not.  So, I may
as well be me.  Then I know if someone likes me, they like me.

Re: [jazzplusplus-devel] Core dumping

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

On Friday 26 March 2004 05:38 am, Matt Kelly wrote:
> In events.h:
>
> Line 546-ish:
>
>      virtual ~tMetaEvent()
>      {
>        delete [] Data;
>      }
>
> In track.cpp:
>
> diff -r1.4 track.cpp
> 1111,1116c1111,1116
> <   tJazzMeta jazz;
> <   jazz.SetAudioMode(audio_mode);
> <   jazz.SetTrackState(State);
> <   jazz.SetTrackDevice(Device);
> <   jazz.SetIntroLength(TheSong->GetIntroLength());
> <   jazz.Write(io);
> ---
>
>  >   tJazzMeta *jazz = new tJazzMeta;
>  >   jazz->SetAudioMode(audio_mode);
>  >   jazz->SetTrackState(State);
>  >   jazz->SetTrackDevice(Device);
>  >   jazz->SetIntroLength(TheSong->GetIntroLength());
>  >   jazz->Write(io);
>
> In jazz.cpp -- the first one is in function
> tConfigEntry::~tConfigEntry(), and the second one is in
> tConfig::~tConfig():
>
>
> diff -r1.6 jazz.cpp
> 101c101,102
> <   delete StrValue;
> ---
>
>  >   if (StrValue)
>  >      delete [] StrValue;
>
> 274c275,276
> <       delete [] Names[i];
> ---
>
>  >       if (Names[i])
>  >           delete  Names[i];

What type is Names?  wxWidgets is supposed to clean itself up, and if tConfig 
is deleting wxWidgets stuff that the library is cleaning up itself, then 
that's what the problem is.

In any case, it looks like tConfig was written before there was wxConfig, 
because it duplicates all of the function of wxConfig.  Anybody willing to 
take a crack at rewriting tConfig to use wxConfig instead?  It's sorta on the 
list of things to do....  ;)

Dave

> Please apply these to the sources.
>
> Maybe I should have write access to the repository?
>
> 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

Never try to outstubborn a cat.
		-- Lazarus Long, "Time Enough for Love"

Re: [jazzplusplus-devel] Core dumping

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

On Thursday 25 March 2004 22:38, Matt Kelly wrote:
> Maybe I should have write access to the repository?

Uh ya, sounds like a good idea. :)  What's your SF id?  There's 2.5 
million Matt Kelly's.

      Patrick

Re: [jazzplusplus-devel] Core dumping

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

On 25 March 2004 at 21:03, Matt Kelly <ra...@ch...> wrote:

> Every time I run the latest and greatest build of JAZZ, when I perform
> a File -> Exit, it dumps core.

Maybe unrelated, but info anyway.  When I linked jazz against lesstif 
version 0.93.34 I got the same behavior.  But, when I quit jazz using 
the window manager controls there was no core dump.  When I linked 
jazz against OpenMotif 2.1, or lesstif >= 0.93.49 the problem went 
away.  The fact that this is happening in an entirely different build 
makes me wonder if jazz is triggering something in the various 
toolkits.  Hmmm....

Re: [jazzplusplus-devel] Core dumping

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

Matt Kelly wrote:
> Perhaps this is a tad premature, but:
> 
> Every time I run the latest and greatest build of JAZZ, when I perform
> a File -> Exit, it dumps core.
> 

Replying to my own post...  I found the source of the valgrind
complaints.  Bad use of 'delete'.

In events.h:

Line 546-ish:

     virtual ~tMetaEvent()
     {
       delete [] Data;
     }

In track.cpp:

diff -r1.4 track.cpp
1111,1116c1111,1116
<   tJazzMeta jazz;
<   jazz.SetAudioMode(audio_mode);
<   jazz.SetTrackState(State);
<   jazz.SetTrackDevice(Device);
<   jazz.SetIntroLength(TheSong->GetIntroLength());
<   jazz.Write(io);
---
 >   tJazzMeta *jazz = new tJazzMeta;
 >   jazz->SetAudioMode(audio_mode);
 >   jazz->SetTrackState(State);
 >   jazz->SetTrackDevice(Device);
 >   jazz->SetIntroLength(TheSong->GetIntroLength());
 >   jazz->Write(io);

In jazz.cpp -- the first one is in function 
tConfigEntry::~tConfigEntry(), and the second one is in
tConfig::~tConfig():


diff -r1.6 jazz.cpp
101c101,102
<   delete StrValue;
---
 >   if (StrValue)
 >      delete [] StrValue;
274c275,276
<       delete [] Names[i];
---
 >       if (Names[i])
 >           delete  Names[i];

Please apply these to the sources.

Maybe I should have write access to the repository?

Matt

[jazzplusplus-devel] Core dumping

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

Perhaps this is a tad premature, but:

Every time I run the latest and greatest build of JAZZ, when I perform
a File -> Exit, it dumps core.

There is a problem with some delete calls in jazz.cpp, which where shown
by valgrind.  I fixed those, but now I get a seg fault.  Valgrind says:

==18348== valgrind's libpthread.so: KLUDGED call to: pthread_cond_destroy
NumConfigNames: 66
==18348==
==18348== Invalid read of size 4
==18348==    at 0x405B79B2: wxVariant::~wxVariant() (in 
/usr/X11R6/lib/libwx_gtk-2.4.so.0.0.0)
==18348==    by 0x405BC2AF: __tcf_4 (in 
/usr/X11R6/lib/libwx_gtk-2.4.so.0.0.0)
==18348==    by 0x408EAD89: __cxa_finalize (in /lib/libc.so.6)
==18348==    by 0x40371061: (within /usr/X11R6/lib/libwx_gtk-2.4.so.0.0.0)
==18348==    Address 0xFFFFFFF4 is not stack'd, malloc'd or free'd
Segmentation fault (core dumped)


I'm guessing this is being caused by a destructor in a global class
which ends up calling the wxVariant destructor.  But, it leaves no
other trace.

The gdb stack trace looks similar:
(gdb) where
#0  0x403c59b2 in wxVariant::~wxVariant() ()
    from /usr/X11R6/lib/libwx_gtk-2.4.so.0
#1  0x403ca2b0 in __tcf_4 () from /usr/X11R6/lib/libwx_gtk-2.4.so.0
#2  0x40723d8a in __cxa_finalize () from /lib/libc.so.6
#3  0x4017f062 in __do_global_dtors_aux ()
    from /usr/X11R6/lib/libwx_gtk-2.4.so.0
#4  0x40444bc6 in _fini () from /usr/X11R6/lib/libwx_gtk-2.4.so.0
#5  0x4000b9a0 in _dl_fini () from /lib/ld-linux.so.2
#6  0x40723b0f in exit () from /lib/libc.so.6
#7  0x4070d8b6 in __libc_start_main () from /lib/libc.so.6

This could be a bugger to find.

Oh.  I guess I meant to ask if anyone else is seeing this?

The fix I put in for the delete problem is in jazz.cpp:

diff -r1.6 jazz.cpp
274c274,275
<       delete [] Names[i];
---
 >       if (Names[i])
 >           delete  Names[i];


More in context:

tConfig::~tConfig()
{
    int i;
    for (i = 0; i < NumConfigNames; i++)
    {
       if (Names[i])
           delete  Names[i];
    }
}


I'm also chasing an odd new/delete mismatch in track.cpp which is being
caused by old code.  I'll post the fix when I find it.

Matt

Re: [jazzplusplus-devel] more dialog implementation queries

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

On Thursday 25 March 2004 08:49 pm, joakim verona wrote:
> I suspect it's by design, because I couldnt find a "double" capable
> slider either.

I strongly suggest checking out the sliders in Audacity.  They're real nice, 
have tooltips already to show the values stored, and are capable of 
displaying several different units of volume.  They're both easy and hard to 
use, though.  :(

> I could of course use longs in the gui, and convert to double when
> sending to the command object.
>
> However, how would I show the user a float in the gui in that case?
>
> BTW there are some other issues here. The old code is full of global
> scope variables, which I find un-beautiful.
> In this case "scale" and so on would be global.  It was used so that the
> dialog would remember state between invocations.

All of these global variables are completely wrong.  ;)  I'm working on 
factoring them all out into jppProject, and you can take a crack at it 
already (I've added jppProject to the cvs now, even if it's not doing much 
yet).  We need to collect all the global variables into jppProject (as much 
as it makes sense, anyway) and then write some solid interfaces to them 
within jppProject so we can then free the data from the implementation.

Dave

> Do you still think this is the right way to do it?
>
>
> Cheers,
> /Joakim
>
>
>
> -------------------------------------------------------
> 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

Win98 is called Win98 because there is a 98% probability that it will crash
during installation

[jazzplusplus-devel] more dialog implementation queries

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

I was going to try out my new shiny xml resource based dialog with the 
following code:

////JAVE
/// this is a test to see how to implement a dialog with patricks system
/// it replaces tMidiDelayDlg
void tPianoWin::ActMidiDelayDialog()
{
  double scale = 0.5;
  long clockDelay = 10;
  int repeat = 6;

  jppResourceDialog dialog(this, "midiDelay");
 
  dialog.Attach("scale", &scale);
  dialog.Attach("clockDelay", &clockDelay);
  dialog.Attach("repeat", &repeat);

  if(dialog.ShowModal() == wxID_OK) {
    //execute the command
//     tCmdMidiDelay cmd(Filter, scale,clockDelay,repeat);
//     cmd.Execute();

    Setup();//??
    Canvas->SetScrollRanges();
    Redraw();
  }
}
////////////


It fails, because there are only long* prototypes of Attach.
Is this so by design or because floats havent been implemented?

I suspect it's by design, because I couldnt find a "double" capable 
slider either.

I could of course use longs in the gui, and convert to double when 
sending to the command object.

However, how would I show the user a float in the gui in that case?

BTW there are some other issues here. The old code is full of global 
scope variables, which I find un-beautiful.
In this case "scale" and so on would be global.  It was used so that the 
dialog would remember state between invocations.

Do you still think this is the right way to do it?


Cheers,
/Joakim

Re: [jazzplusplus-devel] PortMidi

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

> 
> Well, I took the plunge and added portmidi to the repository.  I made 
> no attempt to make it compile along with the rest of the system.  If 
> anyone wants another concrete task to perform, making it compile 
> certainly is one.
> 
>         Patrick

I grabbed this, and it didn't quite compile.  I had to make the following
change to make it all work.  Note that this isn't stitched into the main
make flow -- it just makes it compile:

warp>> cvs -z3 -d:pserver:ano...@cv...:/cvsroot/jazzplusplus diff Makefile
Index: Makefile
===================================================================
RCS file: /cvsroot/jazzplusplus/jazz/portmidi/Makefile,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 Makefile
47,48c47,48
< pm_test/latency: Makefile $(ptlib) pm_test/latency.o 
<       $(CC) pm_test/latency.c -o pm_test/latency $(ptlib) -lpthread -lm
---
> pm_test/latency: Makefile $(ptlib) $(pmlib) pm_test/latency.o 
>       $(CC) pm_test/latency.c -o pm_test/latency $(ptlib) $(pmlib) $(ALSALIB) -lpthread -lm


Matt

[jazzplusplus-devel] Memory leak

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

I think I just committed a memory leak.  Sorry!  I created the gProject object 
in OnInit(), but I must admit I'm not certain where to destroy it.

:(

Dave

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

Data, n.:
	An accrual of straws on the backs of theories.

[jazzplusplus-devel] PortMidi

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

Well, I took the plunge and added portmidi to the repository.  I made 
no attempt to make it compile along with the rest of the system.  If 
anyone wants another concrete task to perform, making it compile 
certainly is one.

        Patrick

Re: [jazzplusplus-devel] how to port mididelay dialog to new system?

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

On Wednesday 24 March 2004 14:45, Dave Fancella wrote:
> On Thursday 25 March 2004 05:40 am, Patrick Earl wrote:
> > > Is this "Attach" method part of wxWindows already?  It looks
> > > familiar....
> >
> > Hmm, I hope not... otherwise I just re-invented the wheel.
>
> In that case, the decision is made.  :)  Do this "Attach" thing and
> blind us with your brilliance.  :)  Seriously!

lol... well, it's already done.  It doesn't yet apply to every 
possible case, but it's not hard to add new widets and data types.  I 
also didn't implement non-modal dialogs... those are next on my todo 
list.  If anyone needs anything right away and doesn't want to do it 
themselves, please let me know... I will implement it as soon as I 
get your mail.

BTW, I wrote quite a bit of doxygen documentation for the 
jppResourceDialog class.  Check it out if you're trying to do that 
stuff.  If it's not good enough, again I'm happy to try and fix it.

I got rid of that crazy *d()))at+++(in+t *)+ stuff.  Okay, so I 
exagerate the mess it was, but only slightly. :P

        Patrick

Re: [jazzplusplus-devel] how to port mididelay dialog to new system?

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

On Thursday 25 March 2004 05:40 am, Patrick Earl wrote:
> > Is this "Attach" method part of wxWindows already?  It looks
> > familiar....
>
> Hmm, I hope not... otherwise I just re-invented the wheel.

In that case, the decision is made.  :)  Do this "Attach" thing and blind us 
with your brilliance.  :)  Seriously!

I have seen Attach used as a method to do things, though, but usually in 
plugin setups and/or threading, I think.  Maybe it's looking familiar because 
every single thread class has an "Attach" method?  ;)

Dave 

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

Give your child mental blocks for Christmas.

Re: [jazzplusplus-devel] Opinion on PortMidi

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

I'm sold.  :)  (I was already an advocate of this anyway)

On Thursday 25 March 2004 05:30 am, Patrick Earl wrote:
> The more I think about it, the more I think it's a good idea to go
> with PortMidi.  Here's how it balances out in my head:
>
> Disadvantages:
> 1.  May be poor support or slow uptake of new APIs.

Without it, or something in its place, we'd have to code to the new APIs 
anyway.  So if we wind up having to code to new APIs, we can add the code to 
PortMIDI instead, since we'd already be coding to new APIs, and then anyone 
else using POrtMIDI gets the code too.  Share and share alike, right?  ;)  In 
the meantime, other people using PortMidi are in the same boat, and we'll 
wind up being able to support APIs we don't have enough time to support 
ourselves.  Reusing code is always good.  ;)

> 2.  May be issues with things like latency that are tricky to handle
> without writing more native code.

Same as #1.  :)

> 3.  Need to maintain an extra external dependency.

Audacity keeps a copy of PortAudio in their source tree, I don't see why we 
can't do the same with PortMIDI and then link it in statically.  In fact, I 
seem to recall that all the PortSound libraries are intended to be used that 
way.  In that fashion, we ensure the user always has the right version, for 
one thing, and we can patch our own copies to fix problems while waiting for 
PortMIDI to either accept our patches or write better fixes.

> 4.  Needing only one code base might lead to complacency and allow the
> midi code to sprawl all over the place.

Yeah, that's a problem that's already there to be fixed in the code.  ;)

> Advantages:
> 1.  Only need to wrote the midi interface code once.
> 2.  Don't need to figure out how to port nicely between Windows, Mac
> OS X, and ALSA.
> 3.  It seems to have support behind it, so I like to think that it
> will be updated.
>
> Addressing the disadvantages, #1 may not be an issue for us.  I mean,
> look at how long it's taking to get wxWin2.4 going!  If we want the
> code sooner, we could always write it for the portmidi team.
>
> As for #2, if there are problems we could either send patches that
> improve things or try writing some small midi code hunks that improve
> the situation.  Hopefully it won't be an issue, but even if it is, we
> can try tricks like SCHED_FIFO, which I suspect we might have to do
> anyways.
>
> #3... probably easier to maintain external dependency than to port
> code.
>
> #4... uh.. uhm... no laziness allowed? :)
>
> So, in summary, my personal opinion is that portmidi is probably the
> way to go.

If there's support here, I was figuring after I had jppProject working well 
enough and reliably enough that everyone could take a crack it I was going to 
take on this project, since the Playback stuff needs rewriting anyway.  (I'm 
really irked by a realtime application deriving from wxTimer for the realtime 
part of the application, sorry)  That could be awhile before I hit it, 
though.  I'd kinda like to redesign the Preferences dialog too, but I'm much 
more worried about the backend stuff right now.

Dave

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

Men often believe -- or pretend -- that the "Law" is something sacred, or
at least a science -- an unfounded assumption very convenient to governments.

Re: [jazzplusplus-devel] how to port mididelay dialog to new system?

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

On Wednesday 24 March 2004 14:27, Dave Fancella wrote:
> To be honest, I'm not particular on *how* the data is pulled from
> the dialog. I'm interested in this Attach method.  Also, bear in
> mind I just came back from php-land yesterday, so it'll take a
> little bit for me to get strongly-typed again.  :(  In any case, I
> was thinking that the absolute best way to take the most advantage
> out of XRC would be to have one single dialog maker using several
> different XRC dialog resources rather than just making a bunch of
> dialogs that all load their resources from a file.  It's entirely
> possible that the XRC system will take care of the whole problem of
> pulling data from the dialog for us.  I seem to recall that in XRC
> you define both the resource name and the type, placement, look,
> etc.  Maybe it just takes care of it for us?  ;)

Well, I don't know precisely what you're refering to, but I do know 
that XRC only specifies the GUI widgets and their layout.  It doesn't 
specify any means for interaction with data.  You're expected to do 
basically wxWindow:::FindWindowByName(dialog, "someWidget") and get 
the data out yourself.  It's not -hard- to get the data out, but it's 
still much easier with a wrapper class doing the dirty work for you.

> Not necessarily, but the associative array deal is far from
> perfect.  It is pretty readable, though, and that's a winning trait
> for it's use in weak-typed languages.

Ya, they're great in dynamically typed languages. :)

> > // "Attach" technique.  This is actual code that would work in
> > the // current system.
> > jppResourceDialog dialog = jppResourceDialog(parent, "myDialog");
> > dialog.Attach("myTextCtrl", &myString);
> > dialog.Attach("myCheckBox", &myBool);
> > dialog.ShowModal();
>
> Is this "Attach" method part of wxWindows already?  It looks
> familiar....

Hmm, I hope not... otherwise I just re-invented the wheel.

        Patrick

Re: [jazzplusplus-devel] how to port mididelay dialog to new system?

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

On Thursday 25 March 2004 05:07 am, Patrick Earl wrote:
> On Wednesday 24 March 2004 16:27, joakim verona wrote:
> > I can design the xml resource,  but where should the rest of the
> > code go, in the new improved layered design?
> >
> > this is what it currently looks like:
> >
> > tCmdMidiDelay, a command class that acts on the track structure.
> > Should this go into a "kernel" dir?

I'm envisioning a jppTrack object that stores the tracks and each track's 
selection.  In fact, I'm probably going to start in on that class tonight.  
You would access a given jppTrack through the gProject instance of 
jppProject.  I've got several ideas for that, I'm curious to see how they all 
play out when I get coding.  :)  In any case, I'm thinking that the way it 
should work is you query the jppTrack for data, either the selected data or 
the entire track, then you get a const pointer to that data.  You do whatever 
you're going to do to it by moving it from your const structure to a new 
structure, and then you commit the new structure and the jppProject class 
will organize the new data.  The idea is to preserve the history of edits and 
stuff and ultimately allow unlimited undo, even across multiple saves.

> I haven't thought about the whole command / project structure, so
> anyone is pretty much an expert compared to me.
>
> > tmidiDelayDlg, a dialog class. Should it be broken out, and put in
> > the dialogs dir?
> > Or, since the code will be trivial, just handled in a function?
>
> I've been trying to answer that question myself, but I haven't come to
> any conclusions.  I do think it would be nice if the bulk of the
> dialog code could be placed in the dialogs dir in many small files.
> That said, the dialogs often need to execute some sort of code
> related to the window they were spawned from.

I don't see any reason this has to remain so.  If you consider that everything 
is an "Action" or a "command", then there should be an interface in the 
jppProject class for performing actions or commands.  So you open your 
dialog, get data from the user, then pass that data to jppProject and tell it 
to execute this action or that command or whatever, and jppProject does the 
execution.  It can use callbacks or events to inform the GUI about its 
progress so the GUI can draw progressbars and so forth.

> One possible solution is to have the dialog act independently, but
> have it call a function defined in an interface.  See
> tButtonLabelInterface for an example of how tMouseCounter interacts
> with the piano window through an interface.   If interfaces were
> used, the dialog file would contain the interface and any code for
> the dialog itself.  The main source file would implement the
> interface in the form of a function, performing whatever
> manipulations were necessary.  In fact, if the interface was
> implemented by something in the kernel, an upper level class could
> simply hook the dialog and the kernel code together though the
> interface.  Am I making sense?  Do I sound sane?  If you think my
> ideas are flawed, I really want to hear about it.

The last half of the paragraph is exactly what's in my mind.  :)

Dave

>        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

History is on our side (as long as we can control the historians).

[jazzplusplus-devel] Opinion on PortMidi

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

The more I think about it, the more I think it's a good idea to go 
with PortMidi.  Here's how it balances out in my head:

Disadvantages:
1.  May be poor support or slow uptake of new APIs.
2.  May be issues with things like latency that are tricky to handle 
without writing more native code.
3.  Need to maintain an extra external dependency.
4.  Needing only one code base might lead to complacency and allow the 
midi code to sprawl all over the place.

Advantages:
1.  Only need to wrote the midi interface code once.
2.  Don't need to figure out how to port nicely between Windows, Mac 
OS X, and ALSA.
3.  It seems to have support behind it, so I like to think that it 
will be updated.

Addressing the disadvantages, #1 may not be an issue for us.  I mean, 
look at how long it's taking to get wxWin2.4 going!  If we want the 
code sooner, we could always write it for the portmidi team.

As for #2, if there are problems we could either send patches that 
improve things or try writing some small midi code hunks that improve 
the situation.  Hopefully it won't be an issue, but even if it is, we 
can try tricks like SCHED_FIFO, which I suspect we might have to do 
anyways.

#3... probably easier to maintain external dependency than to port 
code.

#4... uh.. uhm... no laziness allowed? :)

So, in summary, my personal opinion is that portmidi is probably the 
way to go.

        Patrick

Re: [jazzplusplus-devel] how to port mididelay dialog to new system?

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

On Thursday 25 March 2004 04:55 am, Patrick Earl wrote:
> I also like having one class per file, though I personally don't mind
> having small related utility classes in with the main one.  I used to
> hate that one class one file Java thing. ;)

Well, to go into more detail, I figure that a class that is only used in one 
place is perfectly ok being in that file as well (you'll see me do this 
occasionally).  But if a class gets used by two or more other classes, it 
should be pulled out and stuck in its own file.  That said, I also don't like 
source trees with a bazillion files, and all these files and classes in Jazz 
kinda get on my nerves.  I think we should take Fesic's advice and go 'back 
to the beginning'.  :)

> As to dialogs, one advantage of the "Attach" method is that different
> widgets can be handled automatically.  For example, you could attach
> a long* to a resource named "number".  The user would have the option
> of making "number" a wxTextCtrl, a wxSlider, a wxChoice, etc.

To be honest, I'm not particular on *how* the data is pulled from the dialog.  
I'm interested in this Attach method.  Also, bear in mind I just came back 
from php-land yesterday, so it'll take a little bit for me to get 
strongly-typed again.  :(  In any case, I was thinking that the absolute best 
way to take the most advantage out of XRC would be to have one single dialog 
maker using several different XRC dialog resources rather than just making a 
bunch of dialogs that all load their resources from a file.  It's entirely 
possible that the XRC system will take care of the whole problem of pulling 
data from the dialog for us.  I seem to recall that in XRC you define both 
the resource name and the type, placement, look, etc.  Maybe it just takes 
care of it for us?  ;)

> With the associative array, extra logic would be necessary to know if
> you want, for example, a string or a long.  It seems like there could
> be issues getting the data in the format you want without having to
> write much code for each dialog.

Not necessarily, but the associative array deal is far from perfect.  It is 
pretty readable, though, and that's a winning trait for it's use in 
weak-typed languages.

> I dunno, I'm sure the "Attach" system is far from perfect, but as far
> as I can remember, I haven't seen anything better.  I'd be interested
> in taking a look at the template thing if you happen to remember what
> it is.

It's just a template in STL.  I think you were right when you said it was a 
hash, map, or hashmap, or something like that.  You do:

std::hash<jppDialogData> *DialogData;

jppDialogData is a class you construct to store all the data in.  Or something 
like that.  I'm forgetting how the maps actually work right now.  :(

> BTW, here's an extremely rough comparison of the two techniques:
>
> // "Attach" technique.  This is actual code that would work in the
> // current system.
> jppResourceDialog dialog = jppResourceDialog(parent, "myDialog");
> dialog.Attach("myTextCtrl", &myString);
> dialog.Attach("myCheckBox", &myBool);
> dialog.ShowModal();

Is this "Attach" method part of wxWindows already?  It looks familiar....

> // Associative technique.
> jppResourceDialog dialog = jppResourceDialog(parent, "myDialog");
> if(dialog.ShowModal() == wxID_OK) {
>     myString = dialog.array["myTextControl"].asString();
>     myBool = dialog.array["myCheckBox"].asBool();
> }
>
> If the associative version were to be non-modal, it would require data
> manipulation code in both the Apply and Ok handlers.  I'm sure they
> could be combined somehow, but it still needs to run at some point.
> Switching the "Attach" one to non-modal would be as simple as running
> dialog.Show() instead of dialog.ShowModal().
>
> Please tell me if I'm missing some piece of the puzzle, but I honestly
> don't see that it gets any simpler than the first method.
>
> For the STL associative arrays, is it the map and hashmap?  As far as
> I know, those only take keys and values of one type... any type, but
> only one at a time.

Yes, but the type is user-defined.  You can give it a struct or a class, so 
you can actually store whatever data you want.  Build your class just right, 
and you can always extract it in whatever form you want.  I don't know if 
it's the best solution, though.  If it were PHP, it would be.  :)  (Or 
Python, heh.  Anybody want to port Jazz to wxPython?  Then we'd be finished 
with it tomorrow)

Dave

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

He who has imagination without learning has wings but no feet.