MIDIClient.init broken on linux
|
View:
New views
8 Messages
—
Rating Filter:
Alert me
|
 |
MIDIClient.init broken on linux
by Tim Blechmann-2
::
Rate this Message:
hi all,
the commit number 7509 on svn broke MIDIClient.init on linux: ERROR: Primitive '_ListMIDIEndpoints' failed. Failed. RECEIVER: class MIDIClient (082DE560) { instance variables [19] name : Symbol 'MIDIClient' nextclass : class MIDIClockOut (081C2B00) superclass : Symbol 'Object' subclasses : nil methods : nil instVarNames : nil classVarNames : instance of SymbolArray (082DE620, size=3, set=1) iprototype : nil cprototype : instance of Array (082DE660, size=3, set=2) constNames : nil constValues : nil instanceFormat : Integer 0 instanceFlags : Integer 0 classIndex : Integer 449 classFlags : Integer 0 maxSubclassIndex : Integer 449 filenameSymbol : Symbol '/usr/local/share/SuperCollider/ SCClassLibrary/Common/Control/MIDIOut.sc' charPos : Integer 213 classVarIndex : Integer 129 } CALL STACK: MethodError:reportError B7835840 arg this = <instance of PrimitiveFailedError> Nil:handleError B7835A30 arg this = nil arg error = <instance of PrimitiveFailedError> Thread:handleError B7835750 arg this = <instance of Thread> arg error = <instance of PrimitiveFailedError> Object:throw B78355C0 arg this = <instance of PrimitiveFailedError> Object:primitiveFailed B78357B0 arg this = class MIDIClient Meta_MIDIClient:list B78354D0 arg this = class MIDIClient var list = nil Meta_MIDIClient:init B7835340 arg this = class MIDIClient arg inports = nil arg outports = nil Interpreter:interpretPrintCmdLine B7774230 arg this = <instance of Interpreter> var res = nil var func = <instance of Function> var code = "MIDIClient.init;" Process:interpretPrintCmdLine B7835530 arg this = <instance of Main> best, tim -- tim@... http://tim.klingt.org Relying on the government to protect your privacy is like asking a peeping tom to install your window blinds. John Perry Barlow _______________________________________________ Sc-devel mailing list Sc-devel@... http://lists.create.ucsb.edu/mailman/listinfo/sc-devel |
|
|
Re: MIDIClient.init broken on linux
by felix-38
::
Rate this Message:
what changed in that checkin is that it calls MIDIClient.list which is the correct way to find out how many ins/outs you have. does MIDIClient.list not work on linux ? I just compile again and it works. On Sun, May 4, 2008 at 12:08 PM, Tim Blechmann <tim@...> wrote: hi all, _______________________________________________ Sc-devel mailing list Sc-devel@... http://lists.create.ucsb.edu/mailman/listinfo/sc-devel |
|
|
Re: MIDIClient.init broken on linux
by Tim Blechmann-2
::
Rate this Message:
On Sun, 04 May 2008 15:44:58 +0200, felix wrote:
> what changed in that checkin is that it calls MIDIClient.list which is > the correct way to find out how many ins/outs you have. > > does MIDIClient.list not work on linux ? it gives me: ERROR: Primitive '_ListMIDIEndpoints' failed. Failed. RECEIVER: class MIDIClient (084229B0) { instance variables [19] name : Symbol 'MIDIClient' nextclass : class MIDIClockOut (08305750) superclass : Symbol 'Object' subclasses : nil methods : nil instVarNames : nil classVarNames : instance of SymbolArray (08422A70, size=3, set=1) iprototype : nil cprototype : instance of Array (08422AB0, size=3, set=2) constNames : nil constValues : nil instanceFormat : Integer 0 instanceFlags : Integer 0 classIndex : Integer 453 classFlags : Integer 0 maxSubclassIndex : Integer 453 filenameSymbol : Symbol '/usr/local/share/SuperCollider/ SCClassLibrary/Common/Control/MIDIOut.sc' charPos : Integer 213 classVarIndex : Integer 130 } CALL STACK: MethodError:reportError B783D200 arg this = <instance of PrimitiveFailedError> Nil:handleError B783D070 arg this = nil arg error = <instance of PrimitiveFailedError> Thread:handleError B783CFE0 arg this = <instance of Thread> arg error = <instance of PrimitiveFailedError> Object:throw B783CF80 arg this = <instance of PrimitiveFailedError> Object:primitiveFailed B783CDF0 arg this = class MIDIClient Meta_MIDIClient:list B783CD60 arg this = class MIDIClient var list = nil Interpreter:interpretPrintCmdLine B773CDE0 arg this = <instance of Interpreter> var res = nil var func = <instance of Function> var code = "MIDIClient.list" Process:interpretPrintCmdLine B783CAE0 arg this = <instance of Main> not sure, but maybe one has to initialize the midi backend before listing the devices ... tim -- tim@... http://tim.klingt.org The only people for me are the mad ones, the ones who are mad to live, mad to talk, mad to be saved, desirous of everything at the same time, the ones who never yawn or say a commonplace thing, but burn, burn, burn, like fabulous yellow roman candles exploding like spiders across the stars and in the middle you see the blue centerlight pop and everybody goes "Awww! Jack Kerouac _______________________________________________ Sc-devel mailing list Sc-devel@... http://lists.create.ucsb.edu/mailman/listinfo/sc-devel |
|
|
Re: MIDIClient.init broken on linux
by nescivi
::
Rate this Message:
Hiho,
I'll try to look into this in the next week. sincerely, Marije On Sunday 04 May 2008 11:25:16 Tim Blechmann wrote: > On Sun, 04 May 2008 15:44:58 +0200, felix wrote: > > what changed in that checkin is that it calls MIDIClient.list which is > > the correct way to find out how many ins/outs you have. > > > > does MIDIClient.list not work on linux ? > > it gives me: > ERROR: Primitive '_ListMIDIEndpoints' failed. > Failed. > RECEIVER: > class MIDIClient (084229B0) { > instance variables [19] > name : Symbol 'MIDIClient' > nextclass : class MIDIClockOut (08305750) > superclass : Symbol 'Object' > subclasses : nil > methods : nil > instVarNames : nil > classVarNames : instance of SymbolArray (08422A70, size=3, set=1) > iprototype : nil > cprototype : instance of Array (08422AB0, size=3, set=2) > constNames : nil > constValues : nil > instanceFormat : Integer 0 > instanceFlags : Integer 0 > classIndex : Integer 453 > classFlags : Integer 0 > maxSubclassIndex : Integer 453 > filenameSymbol : Symbol '/usr/local/share/SuperCollider/ > SCClassLibrary/Common/Control/MIDIOut.sc' > charPos : Integer 213 > classVarIndex : Integer 130 > } > CALL STACK: > MethodError:reportError B783D200 > arg this = <instance of PrimitiveFailedError> > Nil:handleError B783D070 > arg this = nil > arg error = <instance of PrimitiveFailedError> > Thread:handleError B783CFE0 > arg this = <instance of Thread> > arg error = <instance of PrimitiveFailedError> > Object:throw B783CF80 > arg this = <instance of PrimitiveFailedError> > Object:primitiveFailed B783CDF0 > arg this = class MIDIClient > Meta_MIDIClient:list B783CD60 > arg this = class MIDIClient > var list = nil > Interpreter:interpretPrintCmdLine B773CDE0 > arg this = <instance of Interpreter> > var res = nil > var func = <instance of Function> > var code = "MIDIClient.list" > Process:interpretPrintCmdLine B783CAE0 > arg this = <instance of Main> > > not sure, but maybe one has to initialize the midi backend before listing > the devices ... Sc-devel mailing list Sc-devel@... http://lists.create.ucsb.edu/mailman/listinfo/sc-devel |
|
|
Re: MIDIClient.init broken on linux
by nescivi
::
Rate this Message:
On Sunday 04 May 2008 09:44:58 felix wrote:
> what changed in that checkin is that it calls MIDIClient.list which is the > correct way to find out how many ins/outs you have. > > does MIDIClient.list not work on linux ? MIDIClient.prInit initialises the handle to ALSA for SuperCollider. You can define as many ins and outs on Linux as you want, and this number of ports will be created for SuperCollider, so that SuperCollider will have these ports to connect to. This can be done either through the connect methods inside SC, or through an external patchbay. MIDIClient.list builds the list of available sources and destinations, possibly including SuperCollider's own, but the handle to the ALSA sequencer has to exist. So the MIDI philosophy on Linux is slightly different then on Mac, with more flexibility for patching due to the nature of ALSA (virtual patchbays rule!). A possible solution would be to add a primitive to initialize just the connection with the sequencer without opening any ports. After that any other methods can be used. sincerely, Marije _______________________________________________ Sc-devel mailing list Sc-devel@... http://lists.create.ucsb.edu/mailman/listinfo/sc-devel |
|
|
Re: MIDIClient.init broken on linux
by felix-38
::
Rate this Message:
On Sun, May 4, 2008 at 11:52 PM, nescivi <nescivi@...> wrote:
(on os x) So the MIDI philosophy on Linux is slightly different then on Mac right.
I wonder what the temporary solution should be to get MIDIIn.init working again for linux. should we put a platform check directly into MIDIIn.init ? and then what can be done ? perhaps just skip the .list and go straight to connect initialize. this just means that on linux you have to specify how many ins and outs you want.
sorry, but I'm not in much of a position to suggest the best solution. for those wondering: the bug I was fixing was to make MIDIIn.init automatically connect to all possible os x ports.
_______________________________________________ Sc-devel mailing list Sc-devel@... http://lists.create.ucsb.edu/mailman/listinfo/sc-devel |
|
|
|
|
|
Re: MIDIClient.init broken on linux (rethinking for osx and windows?)
by nescivi
::
Rate this Message:
Hiho,
I committed a fix for now for Linux, but I really would like to get this issue properly looked into... So the question: Is it possible with CocoaMIDI and PortMIDI to just initialize the client, without specifying the number of ports? If so, then we could create the ports, after initializing the MIDI service, and everything would be much cleaner codewise... sincerely, Marije On Sunday 25 May 2008 19:15:15 nescivi wrote: > Hiho, > > On Monday 05 May 2008 12:28:10 you wrote: > > I don't think its needed at all. you would never wish to limit what you > > connected to. the only reason it was like that was because the whole > > midi thing was copied from the API for cocoa. > > but I would have to look at the source code, the cocoa stuff. its a bit > > snakey. > > any further thoughts about this? > If this could be changed to have only the number of ins and outs be > specified when using connect, so, after the list is retrieved. > > sincerely, > Marije > > PS, isn't this an 80's technology? we might as well have been writing > physical letters to and fro about this issue ;) > > > On Mon, May 5, 2008 at 6:01 PM, nescivi <nescivi@...> wrote: > > > How essential is it for MacOSX (and Windows) to define the number of > > > in and outport upon init, if they are later retrieved for connecting > > > with list? > > > I am wondering whether it is strictly necessary to specify the number > > > of ports when initialising SC as a MIDI client. > > > > > > sincerely, > > > Marije > > > > > > On Mon, May 5, 2008 at 11:19 AM, felix <felix@...> > > > > On Sun, May 4, 2008 at 11:52 PM, nescivi <nescivi@...> wrote: > > > > > On Sunday 04 May 2008 09:44:58 felix wrote: > > > > > > what changed in that checkin is that it calls MIDIClient.list > > > > > > which > > > > > > is > > > > > > > the > > > > > > > > > > correct way to find out how many ins/outs you have. > > > > > > > > (on os x) > > > > > > > > > So the MIDI philosophy on Linux is slightly different then on Mac > > > > > > > > right. > > > > > > > > I wonder what the temporary solution should be to get MIDIIn.init > > > > > > working > > > > > > > again for linux. > > > > > > > > should we put a platform check directly into MIDIIn.init ? and then > > > > > > what > > > > > > > can be done ? perhaps just skip the .list and go straight to connect > > > > initialize. this just means that on linux you have to specify how > > > > many > > > > > > ins > > > > > > > and outs you want. > > > > > > > > sorry, but I'm not in much of a position to suggest the best > > > > solution. > > > > > > > > for those wondering: > > > > the bug I was fixing was to make MIDIIn.init automatically connect to > > > > > > all > > > > > > > possible os x ports. > > > > > > > > > A possible solution would be to add a primitive to initialize just > > > > > the connection with the sequencer without opening any ports. After > > > > > that > > > > > > any > > > > > > > other > > > > > > > > > methods can be used. > > > > > > > > > > sincerely, > > > > > Marije > > _______________________________________________ > Sc-devel mailing list > Sc-devel@... > http://lists.create.ucsb.edu/mailman/listinfo/sc-devel _______________________________________________ Sc-devel mailing list Sc-devel@... http://lists.create.ucsb.edu/mailman/listinfo/sc-devel |
| Free Forum Powered by Nabble | Forum Help |