denemo-devel
[Top][All Lists]
Advanced

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

Re: [Denemo-devel] Windows audio driver


From: alex stone
Subject: Re: [Denemo-devel] Windows audio driver
Date: Mon, 14 Dec 2009 09:43:13 +0000

On Mon, Dec 14, 2009 at 9:15 AM, Richard Shann <address@hidden> wrote:
> On Sun, 2009-12-13 at 16:56 +0000, alex stone wrote:
>> >> Not wrong at all. Outside world doesn't need to know. Provided Jack
>> >> can read the client data for global device/port preferences when
>> >> Denemo starts up,
>> >
>> > These don't match - the ports are just a list of names inside denemo
>> -
>> > correct. So what would it mean that "Jack can read..." ? - we aren't
>> > inputting from jack, we output to it. And I was asking do we need to
>> do
>> > anything about this list.
>> > Richard
>> >
>>
>> Sorry, my error in interpretation. No, the list is the list, and
>> that's it. Denemo devices and ports will simply appear as jack
>> clients, when Denemo is started, yes?
>
> still no understanding here. If it is just a list nothing will "simply
> appear as jack clients", we will have to pass the list to jack for that
> to happen.
>
> Thinking about it: in Jack I see three tabs each has a list of lists,
> which it seems is called a list of clients each with its list of ports
> (judging from the heading in qjackctl).
> So - trying to make a match here - what Alex and Jeremiah have set up is
> a list of devices each with a list of ports, which I think means that
> "devices" is synonymous with "clients".
>
> What is not obvious is why you have more than one device/client. But
> perhaps I don't need to care - up to the user how he distributes the
> staffs amongst ports inside devices...

You're right. It's not something to care about.

For large, multi sampler libs, templates with additional devices and
associated ports can, for example, be setup per orchestral section.
i.e.
denemo:1
1st_violins
2nd_violins
violas
cellos
basses

denemo:2
piccolo
flute1
flute2

and so on......

This makes every port possible for external apps, like linuxsampler,
available to denemo. Depending on the work i'm doing, for example, i
might want to choose my miroslav 1st_violins, over my sonic implant
1st_violins. As long as i have a device and port for each, at project
creation time, i can make that decision.

More importantly, it means i can match templates across apps, so a
project template created in Denemo, can be mirrored in openoctave midi
as a template. Matching staff for track,  denemo device and port, for
openoctave midi device and port, for linuxsampler device and port.



>
> Richard
>
>
>
>
> _______________________________________________
> Denemo-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/denemo-devel
>



-- 
www.openoctave.org

address@hidden
address@hidden




reply via email to

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