<br><br><div class="gmail_quote">On Mon, Feb 18, 2013 at 8:35 AM, M Donalies <span dir="ltr"><<a href="mailto:ingeniousnebbish@cox.net" target="_blank">ingeniousnebbish@cox.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Sunday 17 February 2013 08:21:51 Paul Coccoli wrote:<br>
> On Sat, Feb 16, 2013 at 10:33 PM, M Donalies <<a href="mailto:ingeniousnebbish@cox.net">ingeniousnebbish@cox.net</a>><br>
wrote:<br>
</div><div class="im">> > process_callback() calls process_midi_output(), wherein we find:<br>
> >         port_buffer = jack_port_get_buffer(output_port, nframes);<br>
> ><br>
> > Why the nframes parameter? Is there a separate buffer area for each<br>
> > frame?<br>
><br>
> There's a separate buffer for each port.<br>
<br>
</div>Yes, and that's the output_port arg, but what's with nframes? Why isn't the<br>
function simply:  jack_port_get_buffer(output_port) ?<br></blockquote><div><br>because the client may not want to get all the data at once.<br><br>ardour, for example, breaks up the process() cycle internally to deal with "global" scheduled events. so it may ask for the first N frames, then another M, then another P frames until everything is done.<br>
<br>there was another reason at one time too, but the internally engineering of JACK has eliminated that one. <br></div></div>