Re: [Denemo-devel] Windows audio driver

[alex stone]

Ok, had a test run of the latest svn this morning, and the jack
framework seems to be shaping up nicely.

Some observations.

When i rename a port, it takes the name ok, but when i close
preferences, and reopen them, the name is either a) not saved, or b)
missing.
Use case.

I add 4 ports to a device, and name them 1st violins, 2nd violins,
violas, and cellos. I press ok, and save the project, when i reopen
the preferences, the ports have gone, and one is left in its place,
named "midi_out:5" which i presume means the ports have gone, but the
port put in place is the next integer.

When i name ports, and then select by staff preferences to allocate
that port to a staff, unless i've named it first in preferences, i.e.
1st violins, (once i've allocated the port to the staff)  i can no
longer change the name again in preferences.

When i open denemo with an existing file (i.e. $ denemo
/home/alex/test1.denemo), the previously named and saved ports with
the project are renamed back to default, and in some cases are
missing, although this happens randomly, and not with a consistent
pattern to follow.

Finally, a suggestion.

In preferences, could we have a tickable box labelled "Open last
project." So when Denemo starts up, it's automatically opens the last
project, if the box is ticked.

I would reiterate here, that having ports open and close during a
session is not desirable, unless the user specifically makes the
change. Ports should remain open for the duration of the session, even
if they aren't allocated to a staff.

Nice work on staff preferences. That works, and is simple to
understand. I would ask that the drop down box for port selection be
resizable according to the longest port name available. Currently, the
ends of the port names are getting cut off, and it's a bit tough to
allocate ports accurately, when you can't see which integer is which.
I tried this with 32 ports this morning, and it made the task that
much harder.

Great to see Denemo progressing so well!

Alex.

On Sat, Dec 12, 2009 at 8:48 PM, Richard Shann <address@hidden> wrote:
> On Sat, 2009-12-12 at 15:51 +0000, Richard Shann wrote:
>>
>> Your are creating the whole shooting match everytime prefdialog is
>> run.
>> It is true there is no need, but don't bother to change it.
>
> thinking about this, perhaps the cleanest solution is to create the
> gtktreeview called "view" in device_manager.c only once, immediately the
> prefs have been read in (in prefops.c). Don't let it be destroyed by the
> prefdialog window closing (either you have to apply a g_object_ref to
> it, or catch the destroy (delete?) signal I am not sure which). And of
> course, just do nothing if view!=NULL, ie it has already been created
> and it is being called again for refresh purposes - I don't think you
> actually will need to ever call it again though.
> That way the prefs data is always there in the model and can be accessed
> and modified from the view. The cell_edited routines for editing the two
> sorts of cells on the "edited" signal need to update the
> Denemo.prefs.midi_device structure to match...
>
> Richard
>
>
>
>
> _______________________________________________
> Denemo-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/denemo-devel
>



-- 
www.openoctave.org

address@hidden
address@hidden