I am soliciting some help for using an nport serial to Ethernet controller. I Have the nport server installed and configured and on an IP There are 16 COMs starting at COM3 of course
Are there any objects that in pure data that might make it easy to turn 5 projectors on/off with this device? I want to hit it via Network and then use pd to send out rs232 controls
Perhaps it might be easier to make a crossover cable and connect it directly to the PC?
Patrick Pagano, B.S, M.F.A Assistant in Digital Arts and Science Digital Worlds Institute University of Florida, USA. (352)294-2020
On 13/07/12 06:05, Pagano, Patrick wrote:
I am soliciting some help for using an nport serial to Ethernet controller. I Have the nport server installed and configured and on an IP There are 16 COMs starting at COM3 of course
Are there any objects that in pure data that might make it easy to turn 5 projectors on/off with this device? I want to hit it via Network and then use pd to send out rs232 controls
[comport] is for serial ports, assuming that the nport must be providing the driver that makes them show up on your local system as serial ports
Simon
I have that working and com3 through 18 -- it's a 16 port one show up, but I am wondering how to convert/send the commands into the machine language/bits/calls to control the devices.
Sent from my iPhone
On Jul 13, 2012, at 11:48 PM, "Simon Wise" simonzwise@gmail.com wrote:
On 13/07/12 06:05, Pagano, Patrick wrote:
I am soliciting some help for using an nport serial to Ethernet controller. I Have the nport server installed and configured and on an IP There are 16 COMs starting at COM3 of course
Are there any objects that in pure data that might make it easy to turn 5 projectors on/off with this device? I want to hit it via Network and then use pd to send out rs232 controls
[comport] is for serial ports, assuming that the nport must be providing the driver that makes them show up on your local system as serial ports
Simon
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 14/07/12 17:46, Pagano, Patrick wrote:
I have that working and com3 through 18 -- it's a 16 port one show up, but I am wondering how to convert/send the commands into the machine language/bits/calls to control the devices.
how are you connecting the projectors to the serial ports?
unless they have serial ports to control them then you will need some hardware in between ... if they do have serial ports you'll need the control protocol they use .. from the pd side of things [comport] should be able to send the data, once you know what needs to be sent.
While you are setting up and testing it can help to connect a terminal to the port, depending on how the receiving end is behaving, but [comport] works fine on the Pd end. I haven't done it for a few years, but it should still work.
Simon
Dear List,
I'm working on a diy midi-controller and running into some latency problems, the controller is a 'scratch disk' with with a pic microcontroller with usb.
i've build an absolute encoder for it and i'm sending the data or angle as pitchbend data (for high resolution) the speed with which i'm sending the data is way beyond midi-standards, i know...
now when i set up pd to use alsa audio (internal soundcard) and alsa midi, the device works perfect, very smooth.. when i choose jackd as a soundcard, i'm getting getting latency on the midi input..midi input is falling behind, then picking up instantly, falling behind again and so on...like a sawtooth shape..
the settings i choose for jackd have no effect on this..either when i'm using the internal soundcard via jackd -> alsa, or a firewire device via freebob...the latency problem is the same...also with higher audiobuffer settings there is no change in the latency
I disabled alsa sequencer support in jack so midi is running straight to pd..
i know i'm working out of midi standards, but any help to where the problem might be, or simular experiences, would be greatly appreciated...
greets, Rob Bothof
2012/7/14 Rob Bothof rbothof@xs4all.nl
Dear List,
I'm working on a diy midi-controller and running into some latency problems, the controller is a 'scratch disk' with with a pic microcontroller with usb.
i've build an absolute encoder for it and i'm sending the data or angle as pitchbend data (for high resolution) the speed with which i'm sending the data is way beyond midi-standards, i know...
now when i set up pd to use alsa audio (internal soundcard) and alsa midi, the device works perfect, very smooth.. when i choose jackd as a soundcard, i'm getting getting latency on the midi input..midi input is falling behind, then picking up instantly, falling behind again and so on...like a sawtooth shape..
the settings i choose for jackd have no effect on this..either when i'm using the internal soundcard via jackd -> alsa, or a firewire device via freebob...the latency problem is the same...also with higher audiobuffer settings there is no change in the latency
I disabled alsa sequencer support in jack so midi is running straight to pd..
i know i'm working out of midi standards, but any help to where the problem might be, or simular experiences, would be greatly appreciated...
I can't be of much help, but I can chime in with a similar/related experience: So far, each time I tried sending midi note messages from pd to something like Qsynth or Qsampler, using alsamidi via jack the timing is unacceptably messy. [image: Inline afbeelding 1] resluts in: [image: Inline afbeelding 2] you can clearly see the irregularity, and yes, it _is_ audible too... ;)
greets,
Rob Bothof
______________________________**_________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
On 7/14/2012 10:04 PM, tim vets wrote:
2012/7/14 Rob Bothof <rbothof@xs4all.nl mailto:rbothof@xs4all.nl>
Dear List, I'm working on a diy midi-controller and running into some latency problems, the controller is a 'scratch disk' with with a pic microcontroller with usb. i've build an absolute encoder for it and i'm sending the data or angle as pitchbend data (for high resolution) the speed with which i'm sending the data is way beyond midi-standards, i know... now when i set up pd to use alsa audio (internal soundcard) and alsa midi, the device works perfect, very smooth.. when i choose jackd as a soundcard, i'm getting getting latency on the midi input..midi input is falling behind, then picking up instantly, falling behind again and so on...like a sawtooth shape.. the settings i choose for jackd have no effect on this..either when i'm using the internal soundcard via jackd -> alsa, or a firewire device via freebob...the latency problem is the same...also with higher audiobuffer settings there is no change in the latency I disabled alsa sequencer support in jack so midi is running straight to pd.. i know i'm working out of midi standards, but any help to where the problem might be, or simular experiences, would be greatly appreciated...I can't be of much help, but I can chime in with a similar/related experience: So far, each time I tried sending midi note messages from pd to something like Qsynth or Qsampler, using alsamidi via jack the timing is unacceptably messy. Inline afbeelding 1 resluts in: Inline afbeelding 2 you can clearly see the irregularity, and yes, it _is_ audible too... ;)
Hi Tim, thank you for the shared blues on midi timing ;) what i find strange is that i do not use jack for midi, i disabled alsa sequencer in jackd so midi should go directly to pd.
only thing i change is the audio card from alsa to jack...i don't see how this would influence the midi, but it does..
greets, Rob
On 15/07/12 04:26, Rob Bothof wrote:
Hi Tim, thank you for the shared blues on midi timing ;) what i find strange is that i do not use jack for midi, i disabled alsa sequencer in jackd so midi should go directly to pd.
only thing i change is the audio card from alsa to jack...i don't see how this would influence the midi, but it does..
as I understand it jack MIDI is much better than alsa MIDI as far as timing, jitter and latency goes, so if you are wanting to use MIDI this way you are probably better off using jack MIDI. Its on my TODO list to look into it more, someone else could explain in more detail.
If I am correct then jack MIDI is synced to the jack audio timing, while the jitter and so forth in alsa MIDI is something of a hangover from the hardware/serial port history of MIDI.
Simon
On 7/15/2012 8:43 AM, Simon Wise wrote:
On 15/07/12 04:26, Rob Bothof wrote:
Hi Tim, thank you for the shared blues on midi timing ;) what i find strange is that i do not use jack for midi, i disabled alsa sequencer in jackd so midi should go directly to pd.
only thing i change is the audio card from alsa to jack...i don't see how this would influence the midi, but it does..
as I understand it jack MIDI is much better than alsa MIDI as far as timing, jitter and latency goes, so if you are wanting to use MIDI this way you are probably better off using jack MIDI. Its on my TODO list to look into it more, someone else could explain in more detail.
If I am correct then jack MIDI is synced to the jack audio timing, while the jitter and so forth in alsa MIDI is something of a hangover from the hardware/serial port history of MIDI.
Simon
thanx, I thought jack midi was only used by soundcards with midi support, like some firewire cards for example..? but I have solved this for now by using the commandline pd -midiindev 2, routing the raw /dev/midi device device to pd, now it works regarless of the sound, though the default-midi never shows any devices for me...the commandline still works! would be nice if there was a way to route /dev/midi directly to a jackmidi port... i'm gonna check out some of the jack examples for simpleclients..
best, Rob
On 17/07/12 02:07, Rob Bothof wrote:
On 7/15/2012 8:43 AM, Simon Wise wrote:
as I understand it jack MIDI is much better than alsa MIDI as far as timing, jitter and latency goes, so if you are wanting to use MIDI this way you are probably better off using jack MIDI. Its on my TODO list to look into it more, someone else could explain in more detail.
If I am correct then jack MIDI is synced to the jack audio timing, while the jitter and so forth in alsa MIDI is something of a hangover from the hardware/serial port history of MIDI.
Simon
thanx, I thought jack midi was only used by soundcards with midi support, like some firewire cards for example..?
... and several midi applications ... and you can bridge the two different systems if you need to pass midi on to an app that does not support jack-midi.
I am not sure how reasonable it would be for your usb connection to use jack-midi rather than alsa-midi (perhaps jack-midi is mainly for midi between applications rather than with hardware?), but it would be worth looking into as it would help with the timing issues you have, especially as you say you are trying to use midi much faster than the original protocol allowed for ... which is obviously much more possible over usb than serial.
Simon
thanx, I thought jack midi was only used by soundcards with midi support, like some firewire cards for example..?
... and several midi applications ... and you can bridge the two different systems if you need to pass midi on to an app that does not support jack-midi.
I am not sure how reasonable it would be for your usb connection to use jack-midi rather than alsa-midi (perhaps jack-midi is mainly for midi between applications rather than with hardware?), but it would be worth looking into as it would help with the timing issues you have, especially as you say you are trying to use midi much faster than the original protocol allowed for ... which is obviously much more possible over usb than serial.
Simon
thanx for your response Simon, I've been tweeking with the usb endpoints on my device and have already gotten a faster and steadier performance with alsa-midi via jack. but it is a balance of how many bytes you can send at the same time and at what speed, as usb midi also support a bulk mode..you can send up to 64bytes of midi messages at a single call but without a speed request.
but for my purpose right now it works best with 4bytes at 1ms interrupt...as usbmidi is 4bytes i can send 1 message at the time if wanted to use 8 so i can always send the platter info and another midi-message at the same time but then i need to adjust the speed already for it to work properly
though connecting Pd directly to /dev/midi1 has no problem with all this.....i believe jack alsa-midi does a tme sync for midi with the audio. i'm going to see if i can write a simple jackd wrapper for oss /dev/midi from one of the jack simple midi examples, or perhaps someone already did.. it seems a bit useless as the oss usb device is probably an emulation of alsa who is really driving the device, but maybe it works
best, Rob
On 19/07/12 00:40, Rob Bothof wrote:
thanx for your response Simon, I've been tweeking with the usb endpoints on my device and have already gotten a faster and steadier performance with alsa-midi via jack. but it is a balance of how many bytes you can send at the same time and at what speed, as usb midi also support a bulk mode..you can send up to 64bytes of midi messages at a single call but without a speed request.
but for my purpose right now it works best with 4bytes at 1ms interrupt...as usbmidi is 4bytes i can send 1 message at the time if wanted to use 8 so i can always send the platter info and another midi-message at the same time but then i need to adjust the speed already for it to work properly
though connecting Pd directly to /dev/midi1 has no problem with all this.....i believe jack alsa-midi does a tme sync for midi with the audio. i'm going to see if i can write a simple jackd wrapper for oss /dev/midi from one of the jack simple midi examples, or perhaps someone already did.. it seems a bit useless as the oss usb device is probably an emulation of alsa who is really driving the device, but maybe it works
well, let us know how it goes ... I've been meaning to explore this area a bit more and how you get things working will be interesting.
Simon
-
Pagano, Patrick -
Rob Bothof -
Simon Wise -
tim vets