denemo-devel
[Top][All Lists]
Advanced

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

Re: MIDI (was Re: [Denemo-devel] Anacrusis script needed)


From: Richard Shann
Subject: Re: MIDI (was Re: [Denemo-devel] Anacrusis script needed)
Date: Sat, 12 Sep 2009 16:15:47 +0100

On Sat, 2009-09-12 at 09:21 -0500, Jeremiah Benham wrote:
> I have just applied what you mentioned below and all seems good. I  
> created two staffs with notes and pressed play. The data for staff 1  
> was sent to channel 2 and staff 2 was sent to channel 3. Should the  
> defaults not be channels 0 and 1 respectively. Maybe 0 has a special  
> purpose. I don't remember.
no, this is just that users count channels 1-16 which are encoded 0-15
Richard



>  The channel override in staff properties  
> did not seem to work. I will investigate this later.
> 
> Jeremiah
> 
> 
> 
> 
> 
> On Sep 10, 2009, at 11:47 AM, Richard Shann <address@hidden>  
> wrote:
> 
> > On Thu, 2009-09-10 at 08:08 -0500, Jeremiah Benham wrote:
> >>> I recall sending an email
> >>> about code which caused every note being sent twice (IIRC altering
> >> the
> >>> channel), but I don't recall your response...
> >>
> >> I don't know if I responded. I did not have an answer at the time.  
> >> You
> >> seem to have fixed it because it does not do that for me
> > I didn't think I fixed that but I see the channel switching code has  
> > #if
> > 0 before it now. It looks like this:
> >
> >
> > #if 0
> >        /* Before sending, reset channel to 0. XXX: Not very pretty. */
> >        assert(event->midi_buffer_length >= 1);
> >
> >        tmp_status = event->midi_buffer[0];
> >
> >        if (event->midi_buffer[0] >= 0x80 && event->midi_buffer[0] <=  
> > 0xEF)
> >            event->midi_buffer[0] &= 0xF0;
> >
> >        memcpy(buffer, event->midi_buffer, event->midi_buffer_length);
> >
> >        event->midi_buffer[0] = tmp_status;
> > #endif
> >
> >
> > but the code that seems to be operational for actually causing  
> > output is
> > this:
> >
> >        /* First, send it via midi_out. */
> >        track_number = 0;
> >
> > #ifdef JACK_MIDI_NEEDS_NFRAMES
> >        buffer = jack_midi_event_reserve(port_buffers[track_number], t,
> > event->midi_buffer_length, nframes);
> > #else
> >        buffer = jack_midi_event_reserve(port_buffers[track_number], t,
> > event->midi_buffer_length);
> > #endif
> >
> >
> > which means that only one port is used (?) regardless of track (i.e.
> > staff)? And the second output which follows has #if 0 around it and
> > indeed, this does seem to have been caused by a check-in of mine on  
> > 20th
> > August, which is just labelled as "merge of ..." whatever that means.
> > But I didn't realize this had gone in - as I say I didn't understand
> > what this output /* Send it via proper output port. */ was about. Or
> > rather, why there was a first output via the port for track 0.
> >
> > I haven't used jack for a while now so I am not sure if there are  
> > still
> > problems with its output going to unexpected places. Looking at this
> > code now it seems that it will be sending all the output to one  
> > port. Is
> > there a problem sending it to the "right" port?
> > Ah, I see, this code
> >
> > #if 0
> >        /* Send it via proper output port. */
> >        track_number = event->track->track_number -1;
> >
> > #ifdef JACK_MIDI_NEEDS_NFRAMES
> >        buffer = jack_midi_event_reserve(port_buffers[track_number], t,
> > event->midi_buffer_length, nframes);
> > #else
> >        buffer = jack_midi_event_reserve(port_buffers[track_number], t,
> > event->midi_buffer_length);
> > #endif
> >
> >        if (buffer == NULL) {
> >            warn_from_jack_thread_context("jack_midi_event_reserve  
> > failed, NOTE
> > LOST.");
> >            break;
> >        }
> > #endif
> >
> > would get the buffer and then it would need the bytes copying in,  
> > and it
> > is the next bit that was doing that but changing the channel to 0
> > #if 0
> >        /* Before sending, reset channel to 0. XXX: Not very pretty. */
> >        assert(event->midi_buffer_length >= 1);
> >
> >        tmp_status = event->midi_buffer[0];
> >
> >        if (event->midi_buffer[0] >= 0x80 && event->midi_buffer[0] <=  
> > 0xEF)
> >            event->midi_buffer[0] &= 0xF0;
> >
> >        memcpy(buffer, event->midi_buffer, event->midi_buffer_length);
> >
> >        event->midi_buffer[0] = tmp_status;
> > #endif
> >
> > So, what happens if you do everything in the obvious way - you use the
> > right output port and you use the channel as found in the midi_buffer
> > not channel 0?
> >
> > The code would look like this
> >
> >        track_number = event->track->track_number -1;
> >
> > #ifdef JACK_MIDI_NEEDS_NFRAMES
> >        buffer = jack_midi_event_reserve(port_buffers[track_number], t,
> > event->midi_buffer_length, nframes);
> > #else
> >        buffer = jack_midi_event_reserve(port_buffers[track_number], t,
> > event->midi_buffer_length);
> > #endif
> >
> >        if (buffer == NULL) {
> >            warn_from_jack_thread_context("jack_midi_event_reserve  
> > failed, NOTE
> > LOST.");
> >            break;
> >        }
> > #endif
> >        memcpy(buffer, event->midi_buffer, event->midi_buffer_length);
> >
> >
> > while the currently operational code would be omitted thus
> > #if 0
> >        /* First, send it via midi_out. */
> >        track_number = 0;
> > etc
> >
> >
> > If I get time to play with this I will. But do you have any  
> > recollection
> > of what the issues were that caused you to do all that "First, send...
> > Send it via proper output port."?
> >
> > Richard
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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]