denemo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Denemo-devel] MIDI out


From: Richard Shann
Subject: Re: [Denemo-devel] MIDI out
Date: Mon, 05 Jan 2009 18:37:14 +0000

On Mon, 2009-01-05 at 19:03 +0100, Nils Gey wrote:
> You could use just one Jack-port. this port has 16 midi channels anyway, so 
> for them its important that they could be chosen per staff (of course 
> multiple staffs could go into one channel).
> 
> That would be sufficent to route to one output or to several outputs at once. 
> To route to different outputs Denemo must be able to create several different 
> midi-out ports by the user, if needed.
> 
> Not far away from this topic is the bank/program select. Of course one 
> channel can only use one midi-bank, but the bank can be changed with the 
> specific midi-command. So a staff also should have an optional "choose bank" 
> entry and a midi-command-object to enter at any place in the staff itself 
> "change bank" is needed. Of course a standard-bank is only a comfort-function 
> for people who are too lazy to enter a "change bank" right at the start.
> 
> But most samplers don't want the program/bank and run fine without it. Its a 
> more complex step.
> 
> I'm not a Dev but I think this is too much for the next release, at least if 
> it should be over an experimental status.
> 

Yes definitely 0.8.4 release, if someone will do it, we need to get
0.8.2 out now - I'm just tidying the menus which have been annoying me
for a while.
Richard

> Nils
> 
> On Mon, 05 Jan 2009 11:33:47 -0600
> Jeremiah Benham <address@hidden> wrote:
> 
> > On Mon, 2009-01-05 at 09:52 +0000, Richard Shann wrote:
> > > There has been some chat on freenode#denemo with Nils and others about
> > > what the MIDI out (that has so many votes in the denemo poll) actually
> > > means.
> > > For those not there and to summarize what I have understood here are
> > > some thoughts:
> > > 
> > > Just putting out a MIDI note to a libjack output connection in place of
> > > the playnotes which currently goes to the /dev/sequencer or to portaudio
> > > is not what is being talked about.
> > > 
> > > What is meant is (at a minimum) to be able to point to a place in the
> > > score and have denemo promptly start outputting MIDI to libjack. The
> > > MIDI events it would output would correspond to the notes from the
> > > pointed place onwards in the score, including the prevailing
> > > dynamic/crescendo, midi instrument/channel (anything else? - embedded
> > > MIDI commands I guess). Notes that are hanging on at the given point
> > > would not be sounded (so if the given point just contained notes tied
> > > from previous notes, nothing would be heard until a new note started).
> > > The tempo would be a prevailing tempo at the note concerned (so we would
> > > allow an embedded MIDI command that would change the tempo).
> > > 
> > > The actual jackmidi connection is trivial, of course, and someone on
> > > #denemo came up with a sample
> > > http://trac.jackaudio.org/browser/trunk/jack/example-clients/midiseq.c
> > > which shows how to do that.
> > > It is not intended that the user should be allowed to edit the score
> > > while it is being played. So the value of the gui->changecount variable
> > > is fixed for any given playback.
> > 
> > Would we have one output jack port for each staff or would we mash it
> > all into to one jack port?  If each staff is assigned a different port
> > (which I am assuming is what people want) when would the initialization
> > of that port take place? During staff creation time? It could not be
> > just before playback because the I assume the users would want to assign
> > the created jack ports to various soft synths. I guess I am just kind of
> > hung up here on the UI and where to implement it.
> > 
> > Would this feature be for this release or next? 
> > 
> > Jeremiah
> > 
> > > 
> > > What would require a little design is how to create the MIDI events from
> > > the denemo data. I think I have a good idea how to do this:
> > > An initialization stage would be good, partly to avoid excessive
> > > computation while playing & also for convenience of coding. So if this
> > > MIDI output system has not been initialized since the last edit to the
> > > score the first thing that happens is INITIALIZATION: this creates a
> > > list of MIDI events, with links from the notes in the score to first
> > > event that that note triggers. (As mentioned notes that are tied to
> > > earlier notes have no MIDI event).
> > > On requesting playback from a given note, the MIDI events are simply
> > > shovelled out to jackmidi.
> > > There are some extras that are easily incorporated - silencing staffs
> > > etc. but the real work is the INITIALIZATION task.
> > > 
> > > I think it can be done as follows:
> > >   INITIALIZATION: run a special version of exportmidi.c which instead of
> > > writing to a file creates a list (GList* midi_events in the DenemoScore
> > > structure) of MIDI events, putting a link from each note (etc) to the
> > > MIDI event which it causes.
> > > 
> > > To determine if INTIALIZATION is needed, we need to set a variable
> > > (gui->midichangecount) that is set to the gui->changecount when
> > > INITIALIZATION is run, so that if the comparison
> > > midichangecount==changecount fails when the play request is received we
> > > know INITIALIZATION is needed again.
> > > 
> > > As Nils noticed, exportmidi has at least one bug (dynamics) which I have
> > > put in the bug tracker.
> > > 
> > > I hope I have convinced someone that they could afford to devote an
> > > afternoon to implementing this.
> > > 
> > > Richard
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > Denemo-devel mailing list
> > > address@hidden
> > > http://lists.gnu.org/mailman/listinfo/denemo-devel
> > 
> > 
> > 
> > _______________________________________________
> > Denemo-devel mailing list
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/denemo-devel
> > 
> 
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]