hey all
Anyone know where i could start looking if i wanted to dump a wave table to be seen on a onto small lcd display. eg http://www.spikenzielabs.com/SpikenzieLabs/LCD_How_To.html
i'm a total noob at electronics but interested in figuring it out.
t
obama...
bump.
On Sun, Nov 29, 2009 at 10:57 AM, tdrecordable gateswideopen@gmail.comwrote:
hey all
Anyone know where i could start looking if i wanted to dump a wave table to be seen on a onto small lcd display. eg http://www.spikenzielabs.com/SpikenzieLabs/LCD_How_To.html
i'm a total noob at electronics but interested in figuring it out.
t
tdrecordable wrote:
obama...
bump.
On Sun, Nov 29, 2009 at 10:57 AM, tdrecordable gateswideopen@gmail.comwrote:
hey all
Anyone know where i could start looking if i wanted to dump a wave table to be seen on a onto small lcd display. eg http://www.spikenzielabs.com/SpikenzieLabs/LCD_How_To.html
For starters, you would want to use the comport object on the pd side.
When it comes to building the circuitry between the serial port or usb port on your computer and the LCD screen, check out if there is a http://dorkbot.org/ dorkbot group in your area, I am sure someone there could help you.
also check this website. You could check also the arduino site if you want to go into electronics. PD and arduino are friendly :)
2009/12/3 Justin Glenn Smith noisesmith@gmail.com
tdrecordable wrote:
obama...
bump.
On Sun, Nov 29, 2009 at 10:57 AM, tdrecordable <gateswideopen@gmail.com wrote:
hey all
Anyone know where i could start looking if i wanted to dump a wave table
to
be seen on a onto small lcd display. eg http://www.spikenzielabs.com/SpikenzieLabs/LCD_How_To.html
For starters, you would want to use the comport object on the pd side.
When it comes to building the circuitry between the serial port or usb port on your computer and the LCD screen, check out if there is a http://dorkbot.org/ dorkbot group in your area, I am sure someone there could help you.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
sorry, forgot to post the site.... http://lcdsmartie.sourceforge.net/
here it is
2009/12/3 Ricardo Lameiro ricardolameiro@gmail.com
also check this website. You could check also the arduino site if you want to go into electronics. PD and arduino are friendly :)
2009/12/3 Justin Glenn Smith noisesmith@gmail.com
tdrecordable wrote:
obama...
bump.
On Sun, Nov 29, 2009 at 10:57 AM, tdrecordable <gateswideopen@gmail.com wrote:
hey all
Anyone know where i could start looking if i wanted to dump a wave
table to
be seen on a onto small lcd display. eg http://www.spikenzielabs.com/SpikenzieLabs/LCD_How_To.html
For starters, you would want to use the comport object on the pd side.
When it comes to building the circuitry between the serial port or usb port on your computer and the LCD screen, check out if there is a http://dorkbot.org/ dorkbot group in your area, I am sure someone there could help you.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Fagote / Contrafagote Bassoon / Contra-bassoon http://myspace.com/ricardolameiro
I've been lately messing around with a fairly straight forward configuration sending audio from ardour to Pd's adc~ (through jack) and back to ardour via MIDI (for controlling automations) or audio (trivially re-recording Pd's dac~ output).
In the case of MIDI latency seems no perceptible problem.
In the case of audio, where the audio is of course 'processed' in the Pd patch and eventually 'goes back' to ardour, there is latency. This of course is expected for the nature itself of jack, what I'd like to know at this stage is not how to /remove/ latency but the best way(s) to /handle/ it (possibly even through raising the latency itself, as for the moment I'm not doing real-time), for example if there were some way to compensate it automatically (or at least in some 'smart' way). At the moment the best solution is to manually re-align the slightly delayed audio.
Any input welcome.
Kind regards, Lorenzo.
I've been lately messing around with a fairly straight forward configuration sending audio from ardour to Pd's adc~ (through jack) and back to ardour via MIDI (for controlling automations) or audio (trivially re-recording Pd's dac~ output).
In the case of MIDI latency seems no perceptible problem.
In the case of audio, where the audio is of course 'processed' in the Pd patch and eventually 'goes back' to ardour, there is latency. This of course is expected for the nature itself of jack, what I'd like to know at this stage is not how to /remove/ latency but the best way(s) to /handle/ it (possibly even through raising the latency itself, as for the moment I'm not doing real-time), for example if there were some way to compensate it automatically (or at least in some 'smart' way). At the moment the best solution is to manually re-align the slightly delayed audio.
Any input welcome.
Kind regards, Lorenzo.
afaik all the latency introduced by jack is automatically corrected by ardour. so the latency you observe when rerecording in ardour comes from puredata only. there's not much you can do about this, except optimizing your patch. i'm not aware of any manual latency correction in ardour, but maybe i'm wrong, you should ask this on the ardour forum. you could start your sourceaudio with a short and loud click sound, that way it's easier to align later...
regards,
simon
On Thu, 2009-12-03 at 11:50 +0100, Lorenzo wrote:
I've been lately messing around with a fairly straight forward configuration sending audio from ardour to Pd's adc~ (through jack) and back to ardour via MIDI (for controlling automations) or audio (trivially re-recording Pd's dac~ output).
In the case of MIDI latency seems no perceptible problem.
In the case of audio, where the audio is of course 'processed' in the Pd patch and eventually 'goes back' to ardour, there is latency. This of course is expected for the nature itself of jack, what I'd like to know at this stage is not how to remove latency but the best way(s) to handle it (possibly even through raising the latency itself, as for the moment I'm not doing real-time), for example if there were some way to compensate it automatically (or at least in some 'smart' way). At the moment the best solution is to manually re-align the slightly delayed audio.
Any input welcome.
Kind regards, Lorenzo. _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Jack cannot automatically know that PD is reading from jack and then sending back to re-record. Because of how jack is designed, there is an inevitable and predictable delay there - determined by jack, not by pd.
This has been brought up, ardour already automatically compensates for ladspa plugin latency when it has the proper information, so the infrastructure is theoretically there (ideally they could add a "one jack period worth of latency correction" toggle to the UI for each track).
Simon Iten wrote:
afaik all the latency introduced by jack is automatically corrected by ardour. so the latency you observe when rerecording in ardour comes from puredata only. there's not much you can do about this, except optimizing your patch. i'm not aware of any manual latency correction in ardour, but maybe i'm wrong, you should ask this on the ardour forum. you could start your sourceaudio with a short and loud click sound, that way it's easier to align later...
regards,
simon
On Thu, 2009-12-03 at 11:50 +0100, Lorenzo wrote:
I've been lately messing around with a fairly straight forward configuration sending audio from ardour to Pd's adc~ (through jack) and back to ardour via MIDI (for controlling automations) or audio (trivially re-recording Pd's dac~ output).
In the case of MIDI latency seems no perceptible problem.
In the case of audio, where the audio is of course 'processed' in the Pd patch and eventually 'goes back' to ardour, there is latency. This of course is expected for the nature itself of jack, what I'd like to know at this stage is not how to remove latency but the best way(s) to handle it (possibly even through raising the latency itself, as for the moment I'm not doing real-time), for example if there were some way to compensate it automatically (or at least in some 'smart' way). At the moment the best solution is to manually re-align the slightly delayed audio.
Any input welcome.
Kind regards, Lorenzo. _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
thanks for the clarification. i'll ask about the latency correction for jack-clients in the ardour forum. lately there have been some jack plugins around (linuxdsp) so there would be a need for this there as well.
On Tue, 2009-12-22 at 11:41 -0800, Justin Glenn Smith wrote:
Jack cannot automatically know that PD is reading from jack and then sending back to re-record. Because of how jack is designed, there is an inevitable and predictable delay there - determined by jack, not by pd.
This has been brought up, ardour already automatically compensates for ladspa plugin latency when it has the proper information, so the infrastructure is theoretically there (ideally they could add a "one jack period worth of latency correction" toggle to the UI for each track).
Simon Iten wrote:
afaik all the latency introduced by jack is automatically corrected by ardour. so the latency you observe when rerecording in ardour comes from puredata only. there's not much you can do about this, except optimizing your patch. i'm not aware of any manual latency correction in ardour, but maybe i'm wrong, you should ask this on the ardour forum. you could start your sourceaudio with a short and loud click sound, that way it's easier to align later...
regards,
simon
On Thu, 2009-12-03 at 11:50 +0100, Lorenzo wrote:
I've been lately messing around with a fairly straight forward configuration sending audio from ardour to Pd's adc~ (through jack) and back to ardour via MIDI (for controlling automations) or audio (trivially re-recording Pd's dac~ output).
In the case of MIDI latency seems no perceptible problem.
In the case of audio, where the audio is of course 'processed' in the Pd patch and eventually 'goes back' to ardour, there is latency. This of course is expected for the nature itself of jack, what I'd like to know at this stage is not how to remove latency but the best way(s) to handle it (possibly even through raising the latency itself, as for the moment I'm not doing real-time), for example if there were some way to compensate it automatically (or at least in some 'smart' way). At the moment the best solution is to manually re-align the slightly delayed audio.
Any input welcome.
Kind regards, Lorenzo. _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
i asked about this issue on the ardour forum and paul davis (the main developer of ardour) gave this answer:
All JACK clients can report latency on their ports. Pd is not reporting latency correctly on its JACK ports. If it did, the result of the send via Pd would still be aligned correctly.
To correct this you need to use an "artificial latency" plugin (in the SWH plugin set) to fake the latency that Pd is adding. There's no way to know what the number is so you just have to play with it until ardour does the right thing. Oh, and you need to know one other thing: Ardour only does latency updates at each transport stop, so you need to adjust/stop/roll/adjust/stop as necessary.
furthermore, there seems to be latency correction for other jack apps, if they report it.
hope this helps.
is the jack implementation in pd reporting the latency?
On Tue, 2009-12-22 at 17:23 -0300, Simon Iten wrote:
thanks for the clarification. i'll ask about the latency correction for jack-clients in the ardour forum. lately there have been some jack plugins around (linuxdsp) so there would be a need for this there as well.
On Tue, 2009-12-22 at 11:41 -0800, Justin Glenn Smith wrote:
Jack cannot automatically know that PD is reading from jack and then sending back to re-record. Because of how jack is designed, there is an inevitable and predictable delay there - determined by jack, not by pd.
This has been brought up, ardour already automatically compensates for ladspa plugin latency when it has the proper information, so the infrastructure is theoretically there (ideally they could add a "one jack period worth of latency correction" toggle to the UI for each track).
Simon Iten wrote:
afaik all the latency introduced by jack is automatically corrected by ardour. so the latency you observe when rerecording in ardour comes from puredata only. there's not much you can do about this, except optimizing your patch. i'm not aware of any manual latency correction in ardour, but maybe i'm wrong, you should ask this on the ardour forum. you could start your sourceaudio with a short and loud click sound, that way it's easier to align later...
regards,
simon
On Thu, 2009-12-03 at 11:50 +0100, Lorenzo wrote:
I've been lately messing around with a fairly straight forward configuration sending audio from ardour to Pd's adc~ (through jack) and back to ardour via MIDI (for controlling automations) or audio (trivially re-recording Pd's dac~ output).
In the case of MIDI latency seems no perceptible problem.
In the case of audio, where the audio is of course 'processed' in the Pd patch and eventually 'goes back' to ardour, there is latency. This of course is expected for the nature itself of jack, what I'd like to know at this stage is not how to remove latency but the best way(s) to handle it (possibly even through raising the latency itself, as for the moment I'm not doing real-time), for example if there were some way to compensate it automatically (or at least in some 'smart' way). At the moment the best solution is to manually re-align the slightly delayed audio.
Any input welcome.
Kind regards, Lorenzo. _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
i asked about this issue on the ardour forum and paul davis (the main developer of ardour) gave this answer:
All JACK clients can report latency on their ports. Pd is not reporting latency correctly on its JACK ports. If it did, the result of the send via Pd would still be aligned correctly.
To correct this you need to use an "artificial latency" plugin (in the SWH plugin set) to fake the latency that Pd is adding. There's no way to know what the number is so you just have to play with it until ardour does the right thing. Oh, and you need to know one other thing: Ardour only does latency updates at each transport stop, so you need to adjust/stop/roll/adjust/stop as necessary.
furthermore, there seems to be latency correction for other jack apps, if they report it.
hope this helps.
is the jack implementation in pd reporting the latency?
Thanks for taking the time for this.
Lorenzo
On Thu, 2009-12-03 at 11:50 +0100, Lorenzo wrote:
I've been lately messing around with a fairly straight forward configuration sending audio from ardour to Pd's adc~ (through jack) and back to ardour via MIDI (for controlling automations) or audio (trivially re-recording Pd's dac~ output).
In the case of MIDI latency seems no perceptible problem.
In the case of audio, where the audio is of course 'processed' in the Pd patch and eventually 'goes back' to ardour, there is latency. This of course is expected for the nature itself of jack, what I'd like to know at this stage is not how to remove latency but the best way(s) to handle it (possibly even through raising the latency itself, as for the moment I'm not doing real-time), for example if there were some way to compensate it automatically (or at least in some 'smart' way).
you could of course pipe the unprocessed sound through pd as well, and apply a delay that is exactly as long as the "delay" introduced by your processing. then you record both outputs from pd to ardour. you get two new wav files, the unprocessed and the processed, both aligned. that's a little bit a mess i guess... :-)
regards,
simon
At the moment the best solution is to manually re-align the slightly delayed audio.
Any input welcome.
Kind regards, Lorenzo. _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Justin Glenn Smith -
Lorenzo -
Ricardo Lameiro -
Simon Iten -
tdrecordable