Following an idea from Gerhard Daurer, I'd like to look into displaying the waveform of an audiofile in a Gemwin. Gerhard sent me a prototype of a very cool patch combining my Particle Chamber with PMPD and GEM, which uses physical modelling to visually control the granulation of a soundfile. (And I hope he posts this same prototype here soon!)
In his version, he has only a set number of audiofiles to choose from, so he simply loads a JPG of the waveform into the Gemwin. However, I'd like to be able to load any wav file into this and get some visual feedback (i.e. be able to see the peaks). This would be a one-time operation, and not something that would be changing in realtime (except maybe a zoom in and out), however I would like that displaying the peaks doesn't interrupt audio processing (as drawing a table would).
I'd like to use GEM for this so that the various grains could be graphically represented on top of the waveform. I'm open for PDP implementations, but I don't really consider PDP cross-platform so I'd rather stick with GEM.
Any Gemheads out there have an idea of how to go about this?
best, d.
Hallo, derek holzer hat gesagt: // derek holzer wrote:
Following an idea from Gerhard Daurer, I'd like to look into displaying the waveform of an audiofile in a Gemwin. Gerhard sent me a prototype of a very cool patch combining my Particle Chamber with PMPD and GEM, which uses physical modelling to visually control the granulation of a soundfile. (And I hope he posts this same prototype here soon!)
I'm curious, too.
In his version, he has only a set number of audiofiles to choose from, so he simply loads a JPG of the waveform into the Gemwin. However, I'd like to be able to load any wav file into this and get some visual feedback (i.e. be able to see the peaks). This would be a one-time operation, and not something that would be changing in realtime (except maybe a zoom in and out), however I would like that displaying the peaks doesn't interrupt audio processing (as drawing a table would).
I'd like to use GEM for this so that the various grains could be graphically represented on top of the waveform. I'm open for PDP implementations, but I don't really consider PDP cross-platform so I'd rather stick with GEM.
Any Gemheads out there have an idea of how to go about this?
well, I don't qualify as a Gemhead, but I made a simple patch which does this using the method, I use in my msd-editor to render lots of things inside one render command. I have first seen this in Cyrille Henry's patches.
I didn't fiddle with placing the waveform in a nicer way.
Frank Barknecht _ ______footils.org__
_ __latest track: "scans" _ http://footils.org/cms/show/41
Zitat von Frank Barknecht fbar@footils.org:
Hallo, derek holzer hat gesagt: // derek holzer wrote:
Following an idea from Gerhard Daurer, I'd like to look into displaying the waveform of an audiofile in a Gemwin. Gerhard sent me a prototype of a very cool patch combining my Particle Chamber with PMPD and GEM, which uses physical modelling to visually control the granulation of a soundfile. (And I hope he posts this same prototype here soon!)
I'm curious, too.
Hi all!
Yeah, I'll post it soon. Unfortunately I have to tidy it up a bit. AND my Laptop crashed yesterday.. aarghh
But I'll definitely bring it along on the Vienna meeting too..
In his version, he has only a set number of audiofiles to choose from, so he simply loads a JPG of the waveform into the Gemwin. However, I'd like to be able to load any wav file into this and get some visual feedback (i.e. be able to see the peaks). This would be a one-time operation, and not something that would be changing in realtime (except maybe a zoom in and out), however I would like that displaying the peaks doesn't interrupt audio processing (as drawing a table would).
I'd like to use GEM for this so that the various grains could be graphically represented on top of the waveform. I'm open for PDP implementations, but I don't really consider PDP cross-platform so I'd rather stick with GEM.
Any Gemheads out there have an idea of how to go about this?
Actually I asked a similar question as this a few month ago. I also played around a bit with the [curve 2] object and posted my first result on the list too.. But as I couldn't come up (and no-one else) with a effective solution I decided just to use .jpg images of the waveforms (as IOhannes suggested)
Still I would also be very interested in a solution.. I imagine that a [curve] object with an input for a list of points would be very useful..
well, I don't qualify as a Gemhead, but I made a simple patch which does this using the method, I use in my msd-editor to render lots of things inside one render command. I have first seen this in Cyrille Henry's patches.
As my Laptop doesn't work at the moment I can't look at it right now. I'm really curious..
Best wishes geadsch (gerhard daurer)
Hallo, geadsch@controverse.net hat gesagt: // geadsch@controverse.net wrote:
Yeah, I'll post it soon. Unfortunately I have to tidy it up a bit. AND my Laptop crashed yesterday.. aarghh
:(
Actually I asked a similar question as this a few month ago. I also played around a bit with the [curve 2] object and posted my first result on the list too.. But as I couldn't come up (and no-one else) with a effective solution I decided just to use .jpg images of the waveforms (as IOhannes suggested)
Still I would also be very interested in a solution.. I imagine that a [curve] object with an input for a list of points would be very useful..
Now I remember. The approach I took in my suggestion also involves [repeat]. [repeat] is used to divide one GEM render command, which occurs every 50 ms normally, into multiple commands:
[gemhead] | [repeat 50] | [t a b b b ... ]
While the triggered "a"nythings are sent directly to a [curve 3] object - which in the example with in fact behave like 50 [curve]s -, the triggered bangs lookup values stored in a table (the soundfile) using a simple counter as index i to [tabread]. The resulting values are then converted into control points for the curve: One is at "i -y", the other at "i 0" and the third at "i y" which looks like this:
y | . | | |
| | | | ° -y
With "y = [tabread table] at position i".
The index counter is reset to 0 using a bang triggered by [gemhead] before the [repeat] is reached.
If you need to display bigger soundfiles, it would be wise to do some averaging so you don't have to display tens of thousands of curves.
Frank Barknecht _ ______footils.org__
_ __latest track: "scans" _ http://footils.org/cms/show/41
Frank Barknecht wrote:
Hallo,
Still I would also be very interested in a solution.. I imagine that a [curve] object with an input for a list of points would be very useful..
Now I remember. The approach I took in my suggestion also involves [repeat]. [repeat] is used to divide one GEM render command, which occurs every 50 ms normally, into multiple commands: ...
and of course there is [scopeXYZ~] (in the CVS), but this is really a live-scope and it might be rather hairy to get a proper wave-form of an entire WAV-file (otoh, shouldn't be that hard too) it should be way simpler to use (and more efficient) than whatever [curve*]
mfg.ads.r IOhannes
hello,
Actually I asked a similar question as this a few month ago. I also played around a bit with the [curve 2] object and posted my first result on the list too..
[curve 2] is quite slow for drawing a single line, I use an abstraction made with the openGL objects (see attachment) that is compatible with [curve 2], but lot's faster when you have 1000 lines to draw...
But as I couldn't come up (and no-one else) with a effective solution I decided just to use .jpg images of the waveforms (as IOhannes suggested)
Still I would also be very interested in a solution.. I imagine that a [curve] object with an input for a list of points would be very useful..
I don't understand : [curve 5] get inputs for 5 differents points. you can do segmented line abstraction using openGL wrapper (as in [curve2]). what do you want more?
well, I don't qualify as a Gemhead, but I made a simple patch which does this using the method, I use in my msd-editor to render lots of things inside one render command. I have first seen this in Cyrille Henry's patches.
the first time i saw this was in Iohannes (or someone else) examples patch. IMO, this kind of example are really missing in the gem official distribution.
cyrille
#N canvas 409 354 379 280 10; #X obj 31 123 GEMglBegin; #X obj 86 100 GLdefine GL_LINE_STRIP; #X obj 31 13 inlet; #X obj 86 77 loadbang; #X obj 159 13 inlet; #X obj 221 12 inlet; #X obj 31 200 GEMglEnd; #X obj 31 151 GEMglVertex3fv; #X obj 31 175 GEMglVertex3fv; #X connect 0 0 7 0; #X connect 1 0 0 1; #X connect 2 0 0 0; #X connect 3 0 1 0; #X connect 4 0 7 1; #X connect 5 0 8 1; #X connect 7 0 8 0; #X connect 8 0 6 0;
Hallo, cyrille henry hat gesagt: // cyrille henry wrote:
[curve 2] is quite slow for drawing a single line, I use an abstraction made with the openGL objects (see attachment) that is compatible with [curve 2], but lot's faster when you have 1000 lines to draw...
Wow, [curve2] is *at least* twice as fast as [curve 2], as I found out in a little finite elements benchmark (see att.), which requires msd3D and shows 937 links.
Frank Barknecht _ ______footils.org__
_ __latest track: "scans" _ http://footils.org/cms/show/41
Hi!
This has been sitting in my in-box for ages, so today I finally decided to test it. I am trying to use it with Pix' nqpoly4 abstraction in order to get a lot of lines at the same time. But when I do this, I only get one of the lines existent, the others only appear as the end vertices. Any idea why this might be? And even better, how I might go about solving this problem?
cheers,
tim
On Jun 6, 2005, at 2:50 PM, cyrille henry wrote:
hello,
Actually I asked a similar question as this a few month ago. I also played around a bit with the [curve 2] object and posted my first result on the list too..
[curve 2] is quite slow for drawing a single line, I use an abstraction made with the openGL objects (see attachment) that is compatible with [curve 2], but lot's faster when you have 1000 lines to draw... cyrille #N canvas 409 354 379 280 10; #X obj 31 123 GEMglBegin; #X obj 86 100 GLdefine GL_LINE_STRIP; #X obj 31 13 inlet; #X obj 86 77 loadbang; #X obj 159 13 inlet; #X obj 221 12 inlet; #X obj 31 200 GEMglEnd; #X obj 31 151 GEMglVertex3fv; #X obj 31 175 GEMglVertex3fv; #X connect 0 0 7 0; #X connect 1 0 0 1; #X connect 2 0 0 0; #X connect 3 0 1 0; #X connect 4 0 7 1; #X connect 5 0 8 1; #X connect 7 0 8 0; #X connect 8 0 6 0; _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
----- Tim Boykett TIME'S UP::Research Department \ / Industriezeile 33b A-4020 Linz Austria X +43-732-787804(ph) +43-732-7878043(fx) / \ tim@timesup.org http://www.timesup.org
Hi All,
Silly me, it is of course a problem that Pix' nqpoly4 builds the abstractions below it. Thus one needs to have an explicit loadbang replacement, as the normal loadbang does not take place. So installing a small "send loadbang" in the main patch and a "r loadbang" in the abstraction to load the Open GL detail works fine.
Lovely.
Now to see whether it actually improves things....first tests on OSX don't seem to show a great difference between the two. But running audio at the same time, I managed to completely crash the machine using the curve construction. This also had many of the curves replaced by rectangles, another problem. The clever solution works wonderfully, 2000 lines moving, sound almost glitchfree, I would say that it is a success.
YAY! Thanks,
tim
On Jun 6, 2005, at 2:50 PM, cyrille henry wrote:
Howdy all,
geadsch@controverse.net wrote:
Actually I asked a similar question as this a few month ago.
If only I had checked the archives ;-) Did you see this reply?:
aym3ric wrote:
you could dump the content of the array where the sample is stored to pix_set . that's the idea, now you have to manipulate the list a bit of course.
I'll mess around with this idea later today, as well as Frank's suggestion.
d.
Just a thought:
this whole thing of using GEM would be pretty unnecessary if opening a soundfile from the HD or visualizing a table in a graph didn't cause audio dropouts. Then the whole thing could be visualized with several moveable canvases over a graph structure. But I guess that is when I need to move over to the "threaded soundfiler" or "improved GUI" threads...
d.
I second that it would be nice to be able to display waveforms with standard pd. In this respect, opening/saving audio files appears to be the major problem here.
I do get along rather well with the attached hand-made oscilloscope, which draws tables and which can certainly be extended to draw audio file waveforms (some sort of downsampling needed though).
Matthias
derek holzer schrieb:
Just a thought:
this whole thing of using GEM would be pretty unnecessary if opening a soundfile from the HD or visualizing a table in a graph didn't cause audio dropouts. Then the whole thing could be visualized with several moveable canvases over a graph structure. But I guess that is when I need to move over to the "threaded soundfiler" or "improved GUI" threads...
d.
#N canvas 312 131 725 265 10; #X obj 80 -28 adc~; #X obj 76 14 cnv 10 600 150 empty empty empty 0 0 1 16 -241470 -42246 0; #X obj 80 144 tgl 18 0 oo1 empty on/off 24 10 1 8 -262144 -1 -1 1 1 ; #N canvas 90 0 832 750 oszi_1 0; #X obj -2 -51 cnv 15 80 24 empty empty oszi 20 12 1 18 -233017 -1109 0; #X obj 79 -51 cnv 15 120 24 empty empty subpatch 0 12 1 18 -233017 -1109 0; #X obj 560 -27 cnv 15 90 20 empty empty empty 20 12 0 14 -261681 -66577 0; #X obj 391 10 loadbang; #X obj 233 254 delay 1000; #X obj 15 12 inlet~; #X obj 527 488 cnv 15 40 25 empty empty empty 20 12 0 14 -261681 -66577 0; #X obj 470 65 cnv 15 30 30 empty empty empty 20 12 0 14 -261681 -66577 0; #X obj 255 476 cnv 15 40 40 empty empty empty 20 12 0 14 -261681 -66577 0; #X obj 309 224 div 2; #X obj 309 301 pow 0; #X msg 309 278 10; #X obj 352 255 select 0 1; #X msg 352 284 1; #X msg 384 284 3; #X obj 336 328 * 1; #X floatatom 316 180 5 0 0 0 - - -; #X msg 279 104 1; #X msg 352 104 1; #X obj 279 129 + 1; #X obj 352 129 - 1; #X obj 352 154 * -1; #X msg 316 104 0; #X obj 366 375 / 10; #X obj 345 410 * -1; #X obj 291 68 cnv 15 25 30 empty empty empty 20 12 0 14 -261681 -66577 0; #X obj 364 68 cnv 15 25 30 empty empty empty 20 12 0 14 -261681 -66577 0; #X text -4 46 ------------------------------------------------------------ ; #X text 416 46 ----------------------------------; #X obj 42 358 cnv 15 55 20 empty empty empty 20 12 0 14 -261681 -66577 0; #X msg 45 215 0; #X obj 45 240 metro 1000; #X obj 79 272 delay 500; #X obj 123 11 inlet; #X text 169 9 <-- bang to reset; #X text 197 22 overload; #X obj 45 322 pack 8 8; #X msg 79 294 8; #X msg 45 294 14; #X obj 120 120 cnv 15 55 20 empty empty empty 20 12 0 14 -261681 -66577 0; #X obj 336 351 t b f; #X obj 309 255 t b f; #X obj 352 224 mod 2; #X obj 316 200 t f f; #X obj 123 76 t b b; #X obj 2 194 threshold~ 0.98 100 -0.98 100; #X obj 82 165 cnv 15 90 20 empty empty empty 20 12 0 14 -261681 -66577 0; #X obj 490 253 phasor~; #X obj 491 231 sig~; #X obj 491 186 samplerate~; #X obj 259 435 pack 0.1 1 -1; #X obj 560 343 cnv 15 90 20 empty empty empty 20 12 0 14 -261681 -66577 0; #X obj 566 248 cnv 15 60 25 empty empty empty 20 12 0 14 -261681 -66577 0; #X obj 458 461 clip~ -1 1; #X obj 521 -3 block~ 1024; #X obj 491 208 / 1024; #X obj 552 276 / 1000; #X obj 552 298 * 44100; #X obj 491 322 *~ 4410; #X msg 123 106 ; ui_ovl1 color 8 8; #X obj 16 167 tabwrite~ oszi1_buffer; #X msg 45 344 ; ui_ovl1 color $2 $1; #X obj 458 492 tabwrite~ meas1; #X obj 492 345 tabread4~ oszi1_buffer; #X obj 552 253 r s_xtime1; #X obj 458 73 r oo1; #X obj 352 75 r py1; #X obj 279 75 r my1; #X obj 521 -25 table oszi1_buffer 11050; #X msg 577 70 100; #X obj 591 91 cnv 15 60 25 empty empty empty 20 12 0 14 -261681 -66577 0; #X obj 577 96 s r_xtime1; #X msg 259 462 ; meas1 bounds 0 $2 1023 $3 ; meas1 yticks 0 $1 5 ; meas1 ylabel 1060 $3 0 $2; #X obj 458 99 metro 250; #X connect 3 0 4 0; #X connect 3 0 22 0; #X connect 3 0 49 0; #X connect 3 0 69 0; #X connect 4 0 50 0; #X connect 5 0 45 0; #X connect 5 0 60 0; #X connect 9 0 41 0; #X connect 10 0 15 0; #X connect 11 0 10 0; #X connect 12 0 13 0; #X connect 12 1 14 0; #X connect 13 0 15 1; #X connect 14 0 15 1; #X connect 15 0 40 0; #X connect 16 0 19 1; #X connect 16 0 20 1; #X connect 16 0 43 0; #X connect 17 0 19 0; #X connect 18 0 20 0; #X connect 19 0 16 0; #X connect 20 0 21 0; #X connect 21 0 16 0; #X connect 22 0 16 0; #X connect 23 0 50 0; #X connect 24 0 50 2; #X connect 24 0 53 1; #X connect 30 0 31 0; #X connect 31 0 38 0; #X connect 31 0 32 0; #X connect 32 0 37 0; #X connect 33 0 44 0; #X connect 36 0 61 0; #X connect 37 0 36 0; #X connect 38 0 36 0; #X connect 40 0 50 0; #X connect 40 1 23 0; #X connect 40 1 24 0; #X connect 40 1 50 1; #X connect 40 1 53 2; #X connect 41 0 11 0; #X connect 41 1 10 1; #X connect 42 0 12 0; #X connect 43 0 9 0; #X connect 43 1 42 0; #X connect 44 0 59 0; #X connect 44 1 30 0; #X connect 45 0 31 0; #X connect 45 1 31 0; #X connect 47 0 58 0; #X connect 48 0 47 0; #X connect 49 0 55 0; #X connect 49 0 57 1; #X connect 50 0 72 0; #X connect 53 0 62 0; #X connect 55 0 48 0; #X connect 56 0 57 0; #X connect 57 0 58 1; #X connect 58 0 63 0; #X connect 63 0 53 0; #X connect 64 0 56 0; #X connect 65 0 73 0; #X connect 66 0 18 0; #X connect 67 0 17 0; #X connect 69 0 71 0; #X connect 73 0 60 0; #X connect 73 0 62 0; #X coords 0 0 0.00222222 0.00333333 200 140 0; #X restore 80 19 pd oszi_1; #X obj 650 78 bng 12 250 50 0 py1 empty + 1 -10 1 14 -262144 -1 -1 ; #X obj 650 95 bng 12 250 50 0 my1 empty - 3 16 1 18 -262144 -1 -1; #X obj 501 15 cnv 15 15 25 empty empty p 4 10 1 14 -262131 -1 0; #X obj 517 15 cnv 15 30 25 empty empty (t) 0 10 1 14 -262131 -1 0; #X obj 312 16 cnv 15 120 24 empty ui_ovl1 OVERLOAD! 2 11 1 14 -228992 -228992 0; #X obj 152 17 bng 20 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X text 174 19 <-- click to reset; #X obj 559 145 nbx 3 14 0 250 0 0 s_xtime1 r_xtime1 msec 35 8 1 8 -262144 -1 -1 40 256; #N canvas 0 0 450 300 graph2 0; #X array meas1 1024 float 0; #X coords 0 0.3 1023 -0.3 540 100 1; #X restore 80 41 graph; #X obj 81 -7 hip~ 5; #X connect 0 0 13 0; #X connect 9 0 3 1; #X connect 13 0 3 0;
Hallo, Matthias Blau hat gesagt: // Matthias Blau wrote:
I second that it would be nice to be able to display waveforms with standard pd. In this respect, opening/saving audio files appears to be the major problem here.
I do get along rather well with the attached hand-made oscilloscope, which draws tables and which can certainly be extended to draw audio file waveforms (some sort of downsampling needed though).
I often use Scope~ from Cyclone for monitoring signals, It's quite fast, can be resized and zoomed and is generally a very useful little external.
Frank Barknecht _ ______footils.org__
_ __latest track: "scans" _ http://footils.org/cms/show/41
After reading this thread I made a cummulative patch to dispa general view of a wav file in a gem. I use cyrilles gl patch and I average the portions of the wav file that do not get displayed. I think this method gives a better feeling of the contents of the wav file. Please comment and hack.
go to https://www.puredata.info/Members/mrtof and get v33.wavdisplay -> a cummulative patch displaying a general view of a wav file in a gem window.
Tom
On 6/7/05, Frank Barknecht fbar@footils.org wrote:
Hallo, Matthias Blau hat gesagt: // Matthias Blau wrote:
I second that it would be nice to be able to display waveforms with standard pd. In this respect, opening/saving audio files appears to be the major problem here.
I do get along rather well with the attached hand-made oscilloscope, which draws tables and which can certainly be extended to draw audio file waveforms (some sort of downsampling needed though).
I often use Scope~ from Cyclone for monitoring signals, It's quite fast, can be resized and zoomed and is generally a very useful little external.
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: "scans" _ http://footils.org/cms/show/41
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hey Tom,
I'd like your comments on the workshop standard artengine, HC and I are working on:
https://puredata.org/Members/bbogart/PDWorkshops
B.
Thomas Ouellet Fredericks wrote:
After reading this thread I made a cummulative patch to dispa general view of a wav file in a gem. I use cyrilles gl patch and I average the portions of the wav file that do not get displayed. I think this method gives a better feeling of the contents of the wav file. Please comment and hack.
go to https://www.puredata.info/Members/mrtof and get v33.wavdisplay -> a cummulative patch displaying a general view of a wav file in a gem window.
Tom
On 6/7/05, Frank Barknecht fbar@footils.org wrote:
Hallo, Matthias Blau hat gesagt: // Matthias Blau wrote:
I second that it would be nice to be able to display waveforms with standard pd. In this respect, opening/saving audio files appears to be the major problem here.
I do get along rather well with the attached hand-made oscilloscope, which draws tables and which can certainly be extended to draw audio file waveforms (some sort of downsampling needed though).
I often use Scope~ from Cyclone for monitoring signals, It's quite fast, can be resized and zoomed and is generally a very useful little external.
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: "scans" _ http://footils.org/cms/show/41
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
0k this is getting fun https://www.puredata.info/Members/mrtof/v33.livewavdisplay/view -> live audi input display with gem + added fgraphical features
T0m
ps, will check the workshop standard
On 6/7/05, B. Bogart ben@ekran.org wrote:
Hey Tom,
I'd like your comments on the workshop standard artengine, HC and I are working on:
https://puredata.org/Members/bbogart/PDWorkshops
B.
Thomas Ouellet Fredericks wrote:
After reading this thread I made a cummulative patch to dispa general view of a wav file in a gem. I use cyrilles gl patch and I average the portions of the wav file that do not get displayed. I think this method gives a better feeling of the contents of the wav file. Please comment and hack.
go to https://www.puredata.info/Members/mrtof and get v33.wavdisplay -> a cummulative patch displaying a general view of a wav file in a gem window.
Tom
On 6/7/05, Frank Barknecht fbar@footils.org wrote:
Hallo, Matthias Blau hat gesagt: // Matthias Blau wrote:
I second that it would be nice to be able to display waveforms with standard pd. In this respect, opening/saving audio files appears to be the major problem here.
I do get along rather well with the attached hand-made oscilloscope, which draws tables and which can certainly be extended to draw audio file waveforms (some sort of downsampling needed though).
I often use Scope~ from Cyclone for monitoring signals, It's quite fast, can be resized and zoomed and is generally a very useful little external.
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: "scans" _ http://footils.org/cms/show/41
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
well, I see two drawbacks to using Scope~
if you want to get students or more generally, non-pd-freaks, to work with it, on different platforms) 2) lacking documentation for Scope~ (I actually wasn't able to get it working in the sense of adjusting triggering and to meaningfully display any signal with frequency components above a few Hz). Perhaps someone can elucidate me on this issue.
--Matthias
Frank Barknecht schrieb:
I often use Scope~ from Cyclone for monitoring signals, It's quite fast, can be resized and zoomed and is generally a very useful little external.
Ciao
hi Matthias,
Scope~ is as close a clone of cycling74's scope~, as was necessary to make it useful for testing msp clones for compatibility (alongside capture~). Which means, running the same test patches simultaneously in max and pd, and watching for any differences in scope~ displays. Hence, Scope~ is pretty well documented, but this is only a side effect.
Krzysztof
Matthias Blau wrote: ...
- lacking documentation for Scope~ (I actually wasn't able to get it
working in the sense of adjusting triggering and to meaningfully display any signal with frequency components above a few Hz). Perhaps someone can elucidate me on this issue.