Thread: [Line6linux-devel] (no subject)
Status: Pre-Alpha
Brought to you by:
mgrabner
Menu
▾
▴
line6linux-devel
|
From: Andrej K. <de...@an...> - 2013-05-01 09:11:27
|
Hello all, like others tried before me (according to the numerous results on "pod x3 linux"), I'm yet another one to go this way. The usb messages to setup the X3 look simple enough (at least downloading/uploading the profiles+knobs), but knowing nothing about midi and line6linux, I'd like to ask you guys if you have any documentation anywhere. I saw you did quite a rewrite in recent weeks/months, dropping most of the code and putting it into the userspace qt tool. So, is there any documentation for that stuff yet? I mean specifically, how do you plan to support multiple devices using single binary. AFAIK, the pod XT has only single "processing line", X3 has one/two, and the HD500 probably can route signals even more wildly? As I said, I don't know much about MIDI, so it's hard to tell for me, if the messages in X3 (bean) resemble it at all. What's your plan if it's different, is the userspace (planned t be) flexible enough? How is the profile uploading/downloading handled with the XT? BUT the most important question - how is the PCM audio handled? On X3, from the USB dumps it seems that the windows driver simply opens the 0x86/0x2 and the data start to flow. Is it the same with Pod XT too? The X3 should be able to send 4 types of signals (dry+wet+mix+something else), and the dumps also vaguely indicate this - the output data is 1152B each, while the input is 4608B. Does XT do the same, or is there just one signal? I'm asking all this, because I don't want to spend too much time trying to parse the current code, searching for clues :) I gathered the usb interfaces between hw generations are similar in many regards - but it seems like HD300/HD500/X3/XT are quite nicely mixed, featurewise? If you could give me some answers for the above... maybe we'll have the X3 support... hopefully :) -- Best regards, Andrej |
|
From: Stefan H. <ste...@gm...> - 2013-05-01 17:30:52
|
On Wed, May 1, 2013 at 11:11 AM, Andrej Kruták <de...@an...> wrote: > As I said, I don't know much about MIDI, so it's hard to tell for me, if the > messages in X3 (bean) resemble it at all. What's your plan if it's > different, is the userspace (planned t be) flexible enough? How is the > profile uploading/downloading handled with the XT? Userspace should support multiple devices in a data-driven way - adding support for a new device should (mostly) mean populating a table of MIDI messages. I can't help with specifics on your other questions because I only have a POD HD300 and don't know how the X3/XT work. If you have time, please collect USB traffic captures of the interesting features so that you or someone else can implement the needed functionality. Don't expect anything close to the Line6 Editor working yet. Personally, I care about a solid PCM and MIDI driver, but I don't care so much about a Line6 Editor. If someone invests the time then I'm sure it would be doable in a couple of months. Stefan |
|
From: Andrej K. <de...@an...> - 2013-05-01 19:33:44
|
On Wed, May 1, 2013 at 7:30 PM, Stefan Hajnoczi <ste...@gm...> wrote: > On Wed, May 1, 2013 at 11:11 AM, Andrej Kruták <de...@an...> wrote: > > As I said, I don't know much about MIDI, so it's hard to tell for me, if > the > > messages in X3 (bean) resemble it at all. What's your plan if it's > > different, is the userspace (planned t be) flexible enough? How is the > > profile uploading/downloading handled with the XT? > > Userspace should support multiple devices in a data-driven way - > adding support for a new device should (mostly) mean populating a > table of MIDI messages. > > So in case there's no real MIDI in the device, you expect it to be somehow emulated by the driver, right? But for example the volume is send from X3 as a float number, while in MIDI (after a short look) it seems to be just an unsigned char.... > I can't help with specifics on your other questions because I only > have a POD HD300 and don't know how the X3/XT work. If you have time, > please collect USB traffic captures of the interesting features so > that you or someone else can implement the needed functionality. > > Yep, got them already - I think I saw some HD500 captures and they resembled what I see (though just partly). If I can't put the captures to use, I'll send them here for the future generations - it's 6 years old now, so I wonder if there is any real user base for the device anymore (apart from me :) ). Don't expect anything close to the Line6 Editor working yet. > Personally, I care about a solid PCM and MIDI driver, but I don't care > so much about a Line6 Editor. If someone invests the time then I'm > sure it would be doable in a couple of months. > > For me, it'd be enough to just dump all the settings, put (some of) them back through some sys file, for example (or ioctl). According to the USB comm, it seems it's easily doable. Editing would be nice, I saw there's some work around that done already - but as yuo say, someone has to have time for it... :) Andrej |
|
From: Stefan H. <ste...@gm...> - 2013-05-02 14:39:17
|
On Wed, May 1, 2013 at 9:33 PM, Andrej Kruták <de...@an...> wrote: > On Wed, May 1, 2013 at 7:30 PM, Stefan Hajnoczi <ste...@gm...> wrote: >> >> On Wed, May 1, 2013 at 11:11 AM, Andrej Kruták <de...@an...> wrote: >> > As I said, I don't know much about MIDI, so it's hard to tell for me, if >> > the >> > messages in X3 (bean) resemble it at all. What's your plan if it's >> > different, is the userspace (planned t be) flexible enough? How is the >> > profile uploading/downloading handled with the XT? >> >> Userspace should support multiple devices in a data-driven way - >> adding support for a new device should (mostly) mean populating a >> table of MIDI messages. >> > So in case there's no real MIDI in the device, you expect it to be somehow > emulated by the driver, right? But for example the volume is send from X3 as > a float number, while in MIDI (after a short look) it seems to be just an > unsigned char.... No, MIDI is not emulated by the driver. In some cases the driver spies on MIDI traffic or generates MIDI messages internally, but it doesn't process MIDI messages and convert them into Line6-specific I/O operations. MIDI is extensible and you can send arbitrary data over it (may involve a 7-bit encoding). Line6 uses a custom MIDI mapping and parameters can be floats, fixed-point, etc. Can you explain what you mean regarding volume sent as a float? Do you have a traffic capture? >> Don't expect anything close to the Line6 Editor working yet. >> Personally, I care about a solid PCM and MIDI driver, but I don't care >> so much about a Line6 Editor. If someone invests the time then I'm >> sure it would be doable in a couple of months. >> > > For me, it'd be enough to just dump all the settings, put (some of) them > back through some sys file, for example (or ioctl). According to the USB > comm, it seems it's easily doable. Editing would be nice, I saw there's some > work around that done already - but as yuo say, someone has to have time for > it... :) Dumping the device is easy on the HD300, maybe it's the same on yours. The device has a MIDI dump option available in an options menu. You can select whether to dump just the current patch or all patches. When you activate MIDI dump the device sends all the patches over MIDI. On your computer you can use amidi(1) to save this to file. Later you use amidi(1) to send the sysex back to the device, restoring the patch(es). If you don't enjoy using amidi(1) I bet some of the graphical DAWs or MIDI tools under Linux also support storing/loading sysex dumps. Stefan |
|
From: Andrej K. <de...@an...> - 2013-05-02 17:51:39
|
On Thu, May 2, 2013 at 4:39 PM, Stefan Hajnoczi <ste...@gm...> wrote: > On Wed, May 1, 2013 at 9:33 PM, Andrej Kruták <de...@an...> wrote: > > On Wed, May 1, 2013 at 7:30 PM, Stefan Hajnoczi <ste...@gm...> > wrote: > >> > >> On Wed, May 1, 2013 at 11:11 AM, Andrej Kruták <de...@an...> wrote: > >> > As I said, I don't know much about MIDI, so it's hard to tell for me, > if > >> > the > >> > messages in X3 (bean) resemble it at all. What's your plan if it's > >> > different, is the userspace (planned t be) flexible enough? How is the > >> > profile uploading/downloading handled with the XT? > >> > >> Userspace should support multiple devices in a data-driven way - > >> adding support for a new device should (mostly) mean populating a > >> table of MIDI messages. > >> > > So in case there's no real MIDI in the device, you expect it to be > somehow > > emulated by the driver, right? But for example the volume is send from > X3 as > > a float number, while in MIDI (after a short look) it seems to be just an > > unsigned char.... > > No, MIDI is not emulated by the driver. In some cases the driver > spies on MIDI traffic or generates MIDI messages internally, but it > doesn't process MIDI messages and convert them into Line6-specific I/O > operations. > > MIDI is extensible and you can send arbitrary data over it (may > involve a 7-bit encoding). Line6 uses a custom MIDI mapping and > parameters can be floats, fixed-point, etc. > > Can you explain what you mean regarding volume sent as a float? Do > you have a traffic capture? > > This is how the frames look like, either incoming or outcoming. OUT: 1C 00 01 00 | 06 00 0A 40 01 03 00 | 15 00 00 00 00 00 00 03 00 01 00 00 00 05 00 10 3F CE 66 33 3F IN: 1C 00 01 00 | 06 00 0A 03 00 40 00 | 15 00 00 00 00 00 00 03 00 01 00 00 00 05 00 10 3F 70 BE 79 3F My guess is that the first 4 bytes is frame header (more frames can be combined into single packet, first byte is frame len - 4). The second part is the packet header (with type and source/destination flags of some kind, or so it seems - the 40/03 bytes there). I'm not sure if some part of the last thing could be a MIDI message - as I said, I don't know too much in this regard. Anyhow, the last 4 bytes is an IEEE 754 float (seems like it's in big endian). The 05 byte means the volume knob id. So... you said MIDI is extensible - do you think the last part of the above (or last two parts?) could be somehow directly used in the userspace? >> Don't expect anything close to the Line6 Editor working yet. > >> Personally, I care about a solid PCM and MIDI driver, but I don't care > >> so much about a Line6 Editor. If someone invests the time then I'm > >> sure it would be doable in a couple of months. > >> > > > > For me, it'd be enough to just dump all the settings, put (some of) them > > back through some sys file, for example (or ioctl). According to the USB > > comm, it seems it's easily doable. Editing would be nice, I saw there's > some > > work around that done already - but as yuo say, someone has to have time > for > > it... :) > > Dumping the device is easy on the HD300, maybe it's the same on yours. > > Not sure. X3 doesn't support MIDI (no midi in/out ports on the device itself) according to the specs. But I doubt they have completely different HW for X3 and X3 Live (which has MIDI), so the protocol could be the same - and the USB data could be indeed some encoded MIDI messages... The device has a MIDI dump option available in an options menu. You > can select whether to dump just the current patch or all patches. > > When you activate MIDI dump the device sends all the patches over > MIDI. On your computer you can use amidi(1) to save this to file. > > Later you use amidi(1) to send the sysex back to the device, restoring > the patch(es). > > If you don't enjoy using amidi(1) I bet some of the graphical DAWs or > MIDI tools under Linux also support storing/loading sysex dumps. > > I'll try to read something about this (sysex, MIDI format etc.) so I don't bother you with basic stuff.. Anyhow, back to the audio stream. How does the data transfer work on HD300? Is there any setup, or you just read/write the appropriate USB ports? -- Andrej |
|
From: Stefan H. <ste...@gm...> - 2013-05-02 20:51:14
|
On Thu, May 2, 2013 at 7:51 PM, Andrej Kruták <de...@an...> wrote: > On Thu, May 2, 2013 at 4:39 PM, Stefan Hajnoczi <ste...@gm...> wrote: >> >> On Wed, May 1, 2013 at 9:33 PM, Andrej Kruták <de...@an...> wrote: >> > On Wed, May 1, 2013 at 7:30 PM, Stefan Hajnoczi <ste...@gm...> >> > wrote: >> >> >> >> On Wed, May 1, 2013 at 11:11 AM, Andrej Kruták <de...@an...> wrote: >> >> > As I said, I don't know much about MIDI, so it's hard to tell for me, >> >> > if >> >> > the >> >> > messages in X3 (bean) resemble it at all. What's your plan if it's >> >> > different, is the userspace (planned t be) flexible enough? How is >> >> > the >> >> > profile uploading/downloading handled with the XT? >> >> >> >> Userspace should support multiple devices in a data-driven way - >> >> adding support for a new device should (mostly) mean populating a >> >> table of MIDI messages. >> >> >> > So in case there's no real MIDI in the device, you expect it to be >> > somehow >> > emulated by the driver, right? But for example the volume is send from >> > X3 as >> > a float number, while in MIDI (after a short look) it seems to be just >> > an >> > unsigned char.... >> >> No, MIDI is not emulated by the driver. In some cases the driver >> spies on MIDI traffic or generates MIDI messages internally, but it >> doesn't process MIDI messages and convert them into Line6-specific I/O >> operations. >> >> MIDI is extensible and you can send arbitrary data over it (may >> involve a 7-bit encoding). Line6 uses a custom MIDI mapping and >> parameters can be floats, fixed-point, etc. >> >> Can you explain what you mean regarding volume sent as a float? Do >> you have a traffic capture? >> > > This is how the frames look like, either incoming or outcoming. > > OUT: 1C 00 01 00 | 06 00 0A 40 01 03 00 | 15 00 00 00 00 00 00 03 00 01 00 > 00 00 05 00 10 3F CE 66 33 3F > IN: 1C 00 01 00 | 06 00 0A 03 00 40 00 | 15 00 00 00 00 00 00 03 00 01 00 > 00 00 05 00 10 3F 70 BE 79 3F > > My guess is that the first 4 bytes is frame header (more frames can be > combined into single packet, first byte is frame len - 4). The second part > is the packet header (with type and source/destination flags of some kind, > or so it seems - the 40/03 bytes there). I'm not sure if some part of the > last thing could be a MIDI message - as I said, I don't know too much in > this regard. Anyhow, the last 4 bytes is an IEEE 754 float (seems like it's > in big endian). The 05 byte means the volume knob id. > > So... you said MIDI is extensible - do you think the last part of the above > (or last two parts?) could be somehow directly used in the userspace? The CE and BE bytes indicate this is not part of a MIDI message. MIDI data is 7-bit, the top bit must be clear. Therefore this cannot be MIDI. >> >> Don't expect anything close to the Line6 Editor working yet. >> >> Personally, I care about a solid PCM and MIDI driver, but I don't care >> >> so much about a Line6 Editor. If someone invests the time then I'm >> >> sure it would be doable in a couple of months. >> >> >> > >> > For me, it'd be enough to just dump all the settings, put (some of) them >> > back through some sys file, for example (or ioctl). According to the USB >> > comm, it seems it's easily doable. Editing would be nice, I saw there's >> > some >> > work around that done already - but as yuo say, someone has to have time >> > for >> > it... :) >> >> Dumping the device is easy on the HD300, maybe it's the same on yours. >> > Not sure. X3 doesn't support MIDI (no midi in/out ports on the device > itself) according to the specs. But I doubt they have completely different > HW for X3 and X3 Live (which has MIDI), so the protocol could be the same - > and the USB data could be indeed some encoded MIDI messages... > > >> The device has a MIDI dump option available in an options menu. You >> can select whether to dump just the current patch or all patches. >> >> When you activate MIDI dump the device sends all the patches over >> MIDI. On your computer you can use amidi(1) to save this to file. >> >> Later you use amidi(1) to send the sysex back to the device, restoring >> the patch(es). >> >> If you don't enjoy using amidi(1) I bet some of the graphical DAWs or >> MIDI tools under Linux also support storing/loading sysex dumps. >> > I'll try to read something about this (sysex, MIDI format etc.) so I don't > bother you with basic stuff.. http://www.midi.org/techspecs/midimessages.php For example, switching to patch 1 would be: Program Change (channel=0, patch=0): C0 00 By the way, the table shows why MIDI uses 7-bit data. Status bytes have the top bit set, data bytes have the top bit cleared. > Anyhow, back to the audio stream. How does the data transfer work on HD300? > Is there any setup, or you just read/write the appropriate USB ports? HD300 audio is just PCM data sent to/received via isochronous transfer. No setup is required. Some of the other devices have more elaborate setup procedures where several messages are exchanged with the device. But once set up, they also just use iso USB transfers of PCM data. Stefan |
|
From: Markus G. <gr...@ic...> - 2013-05-02 22:15:23
|
On Wednesday 01 May 2013 11:11:00 Andrej Kruták wrote: > Hello all, > > like others tried before me (according to the numerous results on "pod x3 > linux"), I'm yet another one to go this way. > > > The usb messages to setup the X3 look simple enough (at least > downloading/uploading the profiles+knobs), but knowing nothing about midi > and line6linux, I'd like to ask you guys if you have any documentation > anywhere. No, all stuff so far has been implemented by observing the USB traffic while the device communicates with the Windows software provided by Line6. > I saw you did quite a rewrite in recent weeks/months, dropping most of the > code and putting it into the userspace qt tool. Yes, there is ongoing work in https://line6linux.svn.sourceforge.net/svnroot/line6linux/apps/branches/qtbased to build a user space interface to PODxt devices (the only ones available to me for testing), and I tried to keep the code generic enough such that it should be possible to support other Line6 devices as well. Note that the software is currently not based on Qt despite the name of the branch (see https://line6linux.svn.sourceforge.net/svnroot/line6linux/apps/branches/qtbased/README.txt). However, progress has slowed down for two reasons: *) The birth of my son in January :-) *) It is not obvious to which extent the user space library should interpret messages received from the device. The simplest answer would be to interpret nothing at all (e.g., for the PODxt, just deliver the position of the volume knob in the range of 0 to 127, which is the value range of standard MIDI messages). However, it would be more natural to map the volume to a floating point number in the interval 0.0 to 1.0 since the volume always refers to a value between some minimum (zero) and maximum value. By doing so, a graphical representation of the volume knob position would not have to know about the device-specific range of the volume value. However, this can get much more complicated for other parameters. For example, on the PODxt, the actual range of some effect parameters (e.g., delay time) depends on the chosen effect model. As another example, the frequency base for the tuner should be given as an absolute frequency (e.g., 440Hz), independent of the range supported by the device. I tried some time to find a unified solution to this problem, but I think we should go ahead with the simple answer (just use the raw values) and leave a more intelligent mapping as future work. I'm sure it can be done within a C++ class hierarchy representing different devices, but it's not an easy task. > So, is there any documentation for that stuff yet? There is a high-level document which describes the design of the user space software: https://line6linux.svn.sourceforge.net/svnroot/line6linux/apps/branches/qtbased/doc/design.tex (run "cmake .; make" in the "qtbased" directory to create a PDF from the LaTeX source code) Aside from that, I must admit that the source code is poorly documented, but if you are willing to contribute, I'll help you to find the relevant code locations. > I mean specifically, how do you plan to > support multiple devices using single binary. AFAIK, the pod XT has only > single "processing line", X3 has one/two, and the HD500 probably can route > signals even more wildly? This is a good question, and since I only have a PODxt Pro/Live, I don't know an answer. Something like a "select active processing line" command in the user space library might be a solution. Can somebody please comment on the routing capabilities on the X3 and HD500 in some more detail? > As I said, I don't know much about MIDI, so it's hard to tell for me, if > the messages in X3 (bean) resemble it at all. What's your plan if it's > different, is the userspace (planned t be) flexible enough? It is intended to be flexible enough, and if it turns out it isn't, it should be changed. The goal is definitely to support different devices. The family of Line6 devices is mapped to a C++ class hierarchy, where virtual methods should be used to handle device-specific details. > How is the profile uploading/downloading handled with the XT? The PODxt simply transmits a constant sized block of data which encodes all settings in a device-specific way. Without interpreting such data, it is still possible to load and save settings, which I think is the most important use case. Interpretation of profile data and conversion to/from other formats (e.g., *.l6t) should be handled separately IMO. > BUT the most important question - how is the PCM audio handled? On X3, from > the USB dumps it seems that the windows driver simply opens the 0x86/0x2 > and the data start to flow. Is it the same with Pod XT too? The X3 should > be able to send 4 types of signals (dry+wet+mix+something else), and the > dumps also vaguely indicate this - the output data is 1152B each, while the > input is 4608B. Does XT do the same, or is there just one signal? The PODxt always inputs/outputs a 24 bit stereo signal at a sampling rate of 39062.5 Hz (that's the 10MHz USB clock divided by 256, just in case you wonder :-) You can also select different signals, and in case of the dry signal, the left and right channel contain identical data. All of this is certainly task of the kernel driver and not the user space code, except the routing selection as long as it doesn't change the format of the audio data. > I'm asking all this, because I don't want to spend too much time trying to > parse the current code, searching for clues :) I gathered the usb > interfaces between hw generations are similar in many regards - but it > seems like HD300/HD500/X3/XT are quite nicely mixed, featurewise? I can't really comment on this since I only have the XT. I received data dumps for other devices, but it's hard to interpret without the device available for experimenting. Kind regards, Markus |
|
From: Markus G. <gr...@ic...> - 2013-05-02 22:41:21
|
On Thursday 02 May 2013 22:51:04 Stefan Hajnoczi wrote: > On Thu, May 2, 2013 at 7:51 PM, Andrej Kruták <de...@an...> wrote: > > On Thu, May 2, 2013 at 4:39 PM, Stefan Hajnoczi <ste...@gm...> > >> Can you explain what you mean regarding volume sent as a float? Do > >> you have a traffic capture? > > > > This is how the frames look like, either incoming or outcoming. > > > > OUT: 1C 00 01 00 | 06 00 0A 40 01 03 00 | 15 00 00 00 00 00 00 03 00 01 00 > > 00 00 05 00 10 3F CE 66 33 3F > > IN: 1C 00 01 00 | 06 00 0A 03 00 40 00 | 15 00 00 00 00 00 00 03 00 01 00 > > 00 00 05 00 10 3F 70 BE 79 3F > > > > My guess is that the first 4 bytes is frame header (more frames can be > > combined into single packet, first byte is frame len - 4). The second part > > is the packet header (with type and source/destination flags of some kind, > > or so it seems - the 40/03 bytes there). I'm not sure if some part of the > > last thing could be a MIDI message - as I said, I don't know too much in > > this regard. Anyhow, the last 4 bytes is an IEEE 754 float (seems like > > it's > > in big endian). The 05 byte means the volume knob id. > > > > So... you said MIDI is extensible - do you think the last part of the > > above > > (or last two parts?) could be somehow directly used in the userspace? > > The CE and BE bytes indicate this is not part of a MIDI message. MIDI > data is 7-bit, the top bit must be clear. Therefore this cannot be > MIDI. Damn :-( This makes things more complicated in two ways: *) My previous proposal to use raw values won't work since not only the parameter range, but also the data type differs among devices. So a mapping to the most expressive data type (float in this case) is desirable. *) Technically it is possible to map a virtual MIDI device to the USB interface (just as it is done by the PODxt driver) and then send arbitrary (not necessarily MIDI-conforming) data to that device. However, this is at least confusing since such device would be listed among available MIDI devices although it doesn't follow the MIDI standard. I tried to use libusb to directly access the USB interface in user-space code, but this requires to claim the interface, which is not possible if PCM data is transmitted over the interface at the same time by the kernel driver. This raises two questions: -) Is it possible to access a USB interface by libusb which is currently claimed by a kernel driver? -) If MIDI is not appropriate, which other interface can be used by the kernel driver as a "link" between the USB interface and user-space code? Do you have any suggestions? Kind regards, Markus |
|
From: Andrej K. <de...@an...> - 2013-05-04 11:18:09
|
On Fri, May 3, 2013 at 12:40 AM, Markus Grabner <gr...@ic...>wrote: > On Thursday 02 May 2013 22:51:04 Stefan Hajnoczi wrote: > > On Thu, May 2, 2013 at 7:51 PM, Andrej Kruták <de...@an...> wrote: > > > On Thu, May 2, 2013 at 4:39 PM, Stefan Hajnoczi <ste...@gm...> > > >> Can you explain what you mean regarding volume sent as a float? Do > > >> you have a traffic capture? > > > > > > This is how the frames look like, either incoming or outcoming. > > > > > > OUT: 1C 00 01 00 | 06 00 0A 40 01 03 00 | 15 00 00 00 00 00 00 03 00 > 01 00 > > > 00 00 05 00 10 3F CE 66 33 3F > > > IN: 1C 00 01 00 | 06 00 0A 03 00 40 00 | 15 00 00 00 00 00 00 03 00 > 01 00 > > > 00 00 05 00 10 3F 70 BE 79 3F > > > > > > My guess is that the first 4 bytes is frame header (more frames can be > > > combined into single packet, first byte is frame len - 4). The second > part > > > is the packet header (with type and source/destination flags of some > kind, > > > or so it seems - the 40/03 bytes there). I'm not sure if some part of > the > > > last thing could be a MIDI message - as I said, I don't know too much > in > > > this regard. Anyhow, the last 4 bytes is an IEEE 754 float (seems like > > > it's > > > in big endian). The 05 byte means the volume knob id. > > > > > > So... you said MIDI is extensible - do you think the last part of the > > > above > > > (or last two parts?) could be somehow directly used in the userspace? > > > > The CE and BE bytes indicate this is not part of a MIDI message. MIDI > > data is 7-bit, the top bit must be clear. Therefore this cannot be > > MIDI. > Damn :-( This makes things more complicated in two ways: > > *) My previous proposal to use raw values won't work since not only the > parameter range, but also the data type differs among devices. So a > mapping to > the most expressive data type (float in this case) is desirable. > *) Technically it is possible to map a virtual MIDI device to the USB > interface (just as it is done by the PODxt driver) and then send arbitrary > (not necessarily MIDI-conforming) data to that device. However, this is at > least confusing since such device would be listed among available MIDI > devices > although it doesn't follow the MIDI standard. I tried to use libusb to > directly access the USB interface in user-space code, but this requires to > claim the interface, which is not possible if PCM data is transmitted over > the > interface at the same time by the kernel driver. This raises two questions: > -) Is it possible to access a USB interface by libusb which is currently > claimed by a kernel driver? > -) If MIDI is not appropriate, which other interface can be used by the > kernel > driver as a "link" between the USB interface and user-space code? > Hmm, if it's possible to use arbitrary (number) formats in MIDI, and send some custom data, I'd go this way. To me it makes sense - I would like to be able to change/automate the device's settings by some standard way, and I doubt there's any better standard for this than MIDI. I'll try to figure out the basics of the X3 USB protocol - how to upload/download profiles, and how to set individual knobs (and e.g. input/output ports). All this would be exported via virtual MIDI. The meaning of all the knobs would be up to the userspace, since (as you said), it may change depending on the current settings and requires parsing of the l6f files or whatever. I guess we'll talk once/if I figure it out. I'll have a look on MIDI/SysEx, maybe it will fit somehow? How is the setup of the device "profile" done currently (e.g. changing AMP type) - also via some MIDI command with encoded file attached? The GearBox downloads all the settings from X3 during the start, which are some chunks of data. Also, when AMP type is changed on PC, it seems like the complete profile is uploaded (didn't check the opposite way, maybe it will be simpler). The profiles also are 8-bit (bytes >= 0x80 are present)... We could recode this somehow, to fit it into MIDI (if needed) - or we could export some files into /sys (like profile0...profile32), which would read/write the setting from/to the device. Depends on how it's done now - probably it's not worth rewriting everything (again). BUT. Currently, my device (w/o any intervention) just stopped working even under Windows (gearbox won't talk to it properly, even though I can see USB messages coming from the device like before). I hope it's just some USB cable problem, I'll try it on some other machine, we'll see... This Line6 hardware is very flimsy :-( -- Andrej |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X