Forums > MaxMSP

event -> buffer~ -> event… again



jbm
Feb 25 2006 | 1:27 pm

I know I’ve posted on this sort of thing before, and I know there are other topics in this general area, but I’ve yet to find a reliable, working solution.

I need to delay floats by a specified interval. pipe is NOT reliable for this — when the amount of data gets large, pipe hangs Max. I had built a fairly stupid version of an audio-rate pipe, based around seq~, which was basically working, until my needs changed… a little. The design of my patch seems to gag on polyphony. Just too many ints coming into the seq~ at once, or more likely the fact that I was using snapshot~ 1, which I know isn’t a great idea (particularly if you need many instances), to write data to the seq~.

So, has anyone made something like an audio-rate pipe? Or, in order to solve the more basic problem with making this sort of abstraction, has anyone found a good way to convert a signal to a float? I’ve tried building the pipe~ with a buffer~, peek~, and index~, but the data still comes out as a signal, which won’t work in my situation. I noticed that Ben mentioned an object in development to do these conversions, but has anyone found a clever way of doing it in the current version?

Help, please… anybody?

J.


jbm
Feb 25 2006 | 1:56 pm

…expanding on this a little.

An object like snapshot~ works by running at n-times the scheduler rate, and outputting float "snapshots" of the signal at regular intervals. It’s the "at regular intervals" part that seems to cause unnecessary overhead, so, considering that values written to sample locations in a buffer~ will be separated by zeroes, what I’d need to do is to take a similar snapshot every time the buffer~ output jumps above zero. This rather than a continuous stream of snapshots.

Anyway, it’s a matter of communicating between the Max and MSP worlds, and if anybody has any brilliant insights on that, maybe you could just throw in your 2 cents about that?

Or, coming at it from another angle, is it possible to create a bang-triggered snapshot in mxj or mxj~? Topher? Wes? Owen?

J.

Feb 25 2006 | 4:35 pm

On 25 Feb, 2006, at 13:27, jbmaxwell wrote:

> So, has anyone made something like an audio-rate pipe?

Wouldn’t that be tapin~ and tapout~?

L

Lawrence Casserley – lawrence@lcasserley.co.uk
Lawrence Electronic Operations – http://www.lcasserley.co.uk
Colourscape Music Festivals – http://www.colourscape.org.uk


jbm
Feb 25 2006 | 5:17 pm

well, kind of. There’s still the issue of signal to float conversion to deal with though…

J

Feb 25 2006 | 5:29 pm

On around Feb 25, 2006, at 17:35, lawrence casserley said something
like:
>> So, has anyone made something like an audio-rate pipe?
>
> Wouldn’t that be tapin~ and tapout~?

or delay~

— P.
>
————– http://www.bek.no/~pcastine/Litter/ ————–
Peter Castine | ^
| Litter Power & Litter Bundle for Jitter
pcastine@gmx.net |
pcastine@bek.no | iCE: Sequencing, Recording, and Interface Building
4-15@kagi.com | for Max/MSP
| Extremely cool
| http://www.dspaudio.com
| http://www.dspaudio.com/software/software.html


grg
Feb 25 2006 | 6:47 pm

Am 25.02.2006 um 18:17 schrieb jbmaxwell:
> well, kind of. There’s still the issue of signal to float conversion
> to deal with though…

soething like this?
(caveats: zl can only store 256 values, and speed depends on signal
vector size: with 256 10ms intervals are ok, if you want to go faster
you must go lower)

max v2;
#N vpatcher 120 101 778 638;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P message 233 231 41 196617 zlclear;
#P number 208 304 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 163 320 32 196617 print;
#P newex 172 280 46 196617 zl queue;
#P toggle 245 29 15 0;
#P newex 254 53 52 196617 metro 10;
#P newex 202 86 64 196617 random 100;
#P message 70 51 14 196617 2;
#P message 46 56 14 196617 1;
#P user ezdac~ 299 94 343 127 0;
#P message 101 49 14 196617 7;
#P newex 101 240 36 196617 edge~;
#P newex 101 116 27 196617 t b i;
#P newex 101 216 71 196617 tapout~ 1000;
#P newex 101 192 65 196617 tapin~ 1000;
#P newex 101 165 37 196617 click~;
#P connect 9 0 3 0;
#P connect 5 0 3 0;
#P connect 8 0 3 0;
#P connect 7 0 3 0;
#P connect 3 0 0 0;
#P connect 0 0 1 0;
#P connect 1 0 2 0;
#P connect 2 0 4 0;
#P connect 12 0 13 0;
#P connect 15 0 12 0;
#P connect 4 0 12 0;
#P fasten 3 1 12 0 123 151 177 151;
#P connect 10 0 9 0;
#P connect 12 1 14 0;
#P connect 11 0 10 0;
#P pop;


jbm
Feb 25 2006 | 8:15 pm

hmm… that’s the sort of idea, grg.
But the real issue is _anything_ based on regular clocks of the scheduler, so I doubt this would work too well, given that the metro is basically in charge. I essentially want to record floats to a buffer~ (no big deal), start playing through them X ms later (also no big deal), have the whole process on a loop, so that it’s continuous (having problems with this, but that’s because I’m a bit stupid with msp… I seem to remember seeing a third-party external for loop recording somewhere(??)), and on playback get the floats back as floats, _not_ a signal.

So the timing of the floats being both recorded and played back is in the audio domain — that’s what I meant by audio-rate pipe. (And please c74 folks, don’t just tell me that Overdrive will do exactly that, because for whatever reason, the pipe gags, whether overdrive is on or off. Maybe the pipe just can’t handle a large flood of data, but I don’t know its "guts", so I can’t say…) seq~ is basically able to do all of this, except for the continuous recording/playback part.

Using peek~, buffer~, and index~ can do it, all but getting a single float for each output value. Placing a snapshot~ on the output is the best I can hope for, I guess…

thanks for the idea, though.
Any more thoughts are certainly welcome.

J.

Feb 25 2006 | 9:47 pm

Why are you so intent on this float thing? Perhaps you could work in the signal domain?

Or, Maybe you can modify the thing you’re recording to send signals instead of floats…


jbm
Feb 25 2006 | 10:13 pm

It’s a part of the program that deals with events, not audio. I’m trying to do the event scheduling in the audio domain because it’s MUCH less prone to getting bogged down. I’ve built a sampler that analyzes midi data on a 1 second delay (so it can "know" things about note duration, and so on). When you throw a decent amount of logical analysis, and midi input, at a bunch of pipes, the scheduler gags… at least that’s been my experience for the past several years. It’s making me absolutely insane.

I actually got this program working, by fudging a pipe-like object built around seq~. But it wasn’t happy just delaying live midi input (I was sending midi through to a regular piano sample and needed the piano to lock-in with the 1 second delay). AS SOON as I put a pipe in to delay the "live" midi, the whole app started hanging again. I think this is because I’m doing a LOT of logical processing — searching, caching, buffering, and so on, for a library of 30,000+ samples.

The thing that’s annoying me about my program is that the 1 second delay makes it a hassle to use with normal midi instruments. So, I tried to build a simple, delayed, midi-thru channel. Used pipe… Max hangs in no time… well… that’s the whole story.

J.

Feb 26 2006 | 3:31 am

This should do what you need. Note that it’s limited in resolution by
vector size. If you want really high res, wrap the whole thing in a
poly~ at a higher vector size.

Peter McCulloch

max v2;
#N vpatcher 20 74 715 564;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 230 209 48 196617 loadbang;
#P newex 230 232 75 196617 adstatus sigvs;
#P newex 80 285 55 196617 delay~ 64;
#P newex 36 305 31 196617 sah~;
#P button 13 312 15 0;
#P number 195 417 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 195 370 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 151 93 68 196617 0 , 100 5000;
#P newex 151 116 53 196617 line 0. 50;
#P flonum 36 120 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P user hslider 195 394 18 128 128 1 0 0;
#P user hslider 195 345 18 128 128 1 0 0;
#P newex 79 119 31 196617 + 50;
#P toggle 79 36 15 0;
#P newex 79 64 58 196617 metro 100;
#P newex 79 91 59 196617 drunk 30 6;
#P newex 79 150 47 196617 sig~ 60.;
#P newex 79 265 31 196617 abs~;
#P newex 79 180 68 196617 tapin~ 5000;
#P user ezdac~ 300 65 344 98 0;
#P newex 36 415 32 196617 print;
#P flonum 36 365 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 36 339 55 196617 snapshot~;
#P newex 79 306 36 196617 edge~;
#P newex 79 211 71 196617 tapout~ 1000;
#P newex 79 241 46 196617 change~;
#P window linecount 2;
#P comment 312 233 322 196617 snapshot~ only takes one picture per
vector (IIRC) , so you have delay the bang by one vector , otherwise
you won’t get the last value.;
#P connect 2 0 23 0;
#P connect 23 0 4 0;
#P connect 3 0 4 0;
#P connect 22 0 4 0;
#P connect 3 1 4 0;
#P connect 4 0 5 0;
#P connect 5 0 6 0;
#P connect 9 0 23 1;
#P connect 13 0 12 0;
#P connect 12 0 11 0;
#P connect 11 0 14 0;
#P connect 14 0 10 0;
#P fasten 18 0 10 0 156 141 84 141;
#P fasten 17 0 10 0 41 140 84 140;
#P connect 10 0 8 0;
#P connect 8 0 2 0;
#P connect 2 0 1 0;
#P connect 1 0 9 0;
#P connect 24 0 3 0;
#P connect 9 0 24 0;
#P connect 25 1 24 1;
#P connect 19 0 18 0;
#P fasten 14 0 15 0 84 144 200 144;
#P connect 15 0 20 0;
#P fasten 5 0 16 0 41 390 200 390;
#P connect 16 0 21 0;
#P connect 26 0 25 0;
#P pop;


jbm
Feb 26 2006 | 10:23 am

Peter,

This is really close, and certainly the idea is there. But the problem is that it won’t pass a repetition (I had an older model that had the same issue), which in tems of midi really isn’t too great (any isolated note will lose its noteoff).

I’ll see what I can glean from your method, though. Maybe I can just find a work-around for the repetition thing. Good point about the snapshot~ and the vector size — I think that may be why one of my previous attempts didn’t perform as expected.

Thanks.

J.

Feb 26 2006 | 10:41 am


jbm
Feb 26 2006 | 11:12 am

Quote: Trond Lossius wrote on Sun, 26 February 2006 03:41
—————————————————-

> The only problem I can possibly think of with this, is if the flow of
> incomming midi messages are so intense that Max do not manage to
> assign new memory for the coll and pipe used on the fly.

Yes, this is basically the problem. Though I don’t think it’s exactly that, but rather that I’ve got a lot of message passing going on in other areas of the patch, and the pipes just get bogged down waiting for the other stuff to complete (hmm…. "bogging of the pipes", sounds like I need more fibre). To be honest, as I mentioned before, I don’t really understand why the pipe gags, but my problems appear so consistently with introducing delays or pipes that I can’t imagine it’s anything else…(??)

All of the "live" midi input is actually going into an mxj external, which is doing most of the logical stuff: searching for samples, caching "successful" searches, and so on. All I needed to delay originally was the event index, for which Peter’s code above would work just fine (and I may replace my crappy object with Peter’s!). My hanging problem only reappeared when I tried introducing some of the standard pipe objects to sync up a "normal" piano sample (that is, a real-time performed sampler) with the 1-second-delayed stuff. As soon as I put the standard pipe objects in, the patch started hanging again. Ultimately, I’ve realized that I just need a solid, and functionally identical, replica of the behavior of pipe, but without leaving the _timing_ stuff to the scheduler… at least _all_ the evidence points to that conclusion.

To be honest, I’m sure anyone who looked at my complete patch, including the mxj stuff, would probably tell me to do it in C or C++. It’s just an awful lot of picky work. But alas, I only really know Max… and a cobbled-together bit of Java.

thanks for the input.

Still interested in anyone else’s thoughts… (I’m starting to think I should offer a cash prize to the whoever finds the first complete solution!)

J.


jbm
Feb 26 2006 | 11:20 am

…I actually had another thought a while ago, but never asked about it.
I noticed that launching a couple of standalones will actually produce multiple processes (and I’m assuming, multiple instances of the Runtime). So, if I built a sort of client/server system, maybe passing messages over TCP, could I ease the load on my stressed-out scheduler? Has anybody done this sort of thing?

J.

Feb 26 2006 | 12:21 pm

Wouldn’t you be able to do the delay of events inside the java code?
AFAIR there is a clock function in the Max mxj java API? maybe that
would help. Another thing you might check out is Lqueue by Peter
Elsea to see if it might improve the situation.

The patch below seems to indicate some sluggish behavior when pipe is
pushed to hard.

Best,
Trond

#P button 145 498 15 0;
#P user multiSlider 796 105 282 108 0. 1000. 1 3433 15 0 0 2 0 0 0;
#M frgb 0 0 0;
#M brgb 255 255 255;
#M rgb2 127 127 127;
#M rgb3 0 0 0;
#M rgb4 37 52 91;
#M rgb5 74 105 182;
#M rgb6 112 158 18;
#M rgb7 149 211 110;
#M rgb8 187 9 201;
#M rgb9 224 62 37;
#M rgb10 7 114 128;
#P user multiSlider 527 488 282 108 0. 1000. 1 3433 15 0 0 2 0 0 0;
#M frgb 0 0 0;
#M brgb 255 255 255;
#M rgb2 127 127 127;
#M rgb3 0 0 0;
#M rgb4 37 52 91;
#M rgb5 74 105 182;
#M rgb6 112 158 18;
#M rgb7 149 211 110;
#M rgb8 187 9 201;
#M rgb9 224 62 37;
#M rgb10 7 114 128;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 132 397 67 196617 zl group 250;
#P number 312 85 103 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P button 312 32 15 0;
#P newex 312 54 35 196617 timer;
#P newex 447 73 48 196617 loadbang;
#P window linecount 16;
#P message 447 109 313 196617 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39
40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62
63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85
86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106
107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123
124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140
141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157
158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174
175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191
192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208
209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225
226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242
243 244 245 246 247 248 249 250;
#P window linecount 0;
#P message 79 618 634 196617;
#P window linecount 1;
#P newex 79 580 62 196617 prepend set;
#P number 527 469 103 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P button 527 425 15 0;
#P newex 527 446 35 196617 timer;
#P window linecount 16;
#P message 132 109 313 196617 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39
40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62
63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85
86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106
107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123
124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140
141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157
158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174
175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191
192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208
209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225
226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242
243 244 245 246 247 248 249 250;
#P window linecount 1;
#P newex 79 506 36 196617 zl reg;
#P newex 132 469 166 196617 if $f1!=1. then bang else out2 bang;
#P toggle 132 22 15 0;
#P newex 132 56 52 196617 metro 20;
#P flonum 132 450 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 132 427 110 196617 L==;
#P newex 132 369 55 196617 pipe 1000;
#P newex 132 322 25 196617 iter;
#P fasten 19 0 7 1 137 421 110 421;
#P connect 19 0 2 0;
#P fasten 19 0 10 0 137 419 532 419;
#P connect 6 0 7 0;
#P connect 6 0 22 0;
#P connect 18 0 21 0;
#P connect 10 0 9 0;
#P connect 10 0 9 1;
#P connect 11 0 20 0;
#P connect 3 0 6 0;
#P connect 2 0 3 0;
#P connect 1 0 19 0;
#P connect 4 0 8 0;
#P connect 4 0 17 0;
#P connect 17 0 16 0;
#P connect 17 0 16 1;
#P connect 16 0 18 0;
#P connect 15 0 14 0;
#P fasten 14 0 2 1 452 352 237 352;
#P connect 12 0 13 0;
#P connect 7 0 12 0;
#P connect 9 0 11 0;
#P connect 8 0 0 0;
#P connect 5 0 4 0;
#P connect 0 0 1 0;
#P window clipboard copycount 23;


jbm
Feb 26 2006 | 12:31 pm

hey Trond,

Yes, I tried doing the pipe-ing in mxj before, though
not in the same external as the other stuff (I made a
separate mxj for it). It was definitely better, but not
as good as the seq~ based one. I’m messing around with
breaking different tasks into different standalones,
for now, and we’ll see how that goes.

thanks again.

J.


grg
Feb 26 2006 | 2:28 pm

Am 25.02.2006 um 21:15 schrieb jbmaxwell:
> But the real issue is _anything_ based on regular clocks of the
> scheduler, so I doubt this would work too well, given that the metro
> is basically in charge.
Just to clarify: Metro doesn’t do anything here, it just generates
input. The idea is to store the values somewhere in the order they are
received, and do the delay in the audio domain.
cheers, g.


jbm
Feb 26 2006 | 2:38 pm

oh, damn… sorry, grg! too right — I didn’t look at it properly.

This could be good. I’ll try it. It certainly is nice and tight. I’m pretty sure I tried something using click~ before, but I think I used it with delay~, not tapin~/tapout~. So I’ll give your patch a shot in my app.

thanks for pointing it out.

J.


jbm
Feb 26 2006 | 3:06 pm

bummer… that didn’t do it, either. Dropping notes.

But everything seems stable just putting my live, piped midi through a standalone. So, I think maybe the idea of building a client/server type of arrangement might actually be worth some effort. Who knows, by dividing up the overall job between multiple standalones I might even free up the scheduler enough to use the normal pipe object, which is ideal in terms of functionality.

Still, if anyone comes up with the be all, end all of pipe~ objects, please let me know.

Ben, any more news on that external to perform float to signal and signal to float conversions? Is this for an incremental update, or a new version altogether? (i.e., days, weeks, or months away?)

cheers, all. And thanks for the input.

J.

Feb 27 2006 | 12:26 am

How about this? It handles repetitions, as well as 0. The trick is to
separate the sampling from the change~ process. Run it in a poly~ with
a vector size of 4.

Use:

poly~ vs 4 args 10000. 1000. 0.

Peter McCulloch

max v2;
#N vpatcher 10 59 566 613;
#P window setfont "Sans Serif" 9.;
#P newex 207 107 68 196617 tapin~ $1;
#P newex 207 140 71 196617 tapout~ $2;
#P newex 92 53 29 196617 t b f;
#P newex 207 84 37 196617 click~;
#P newex 157 290 27 196617 * 2;
#P newex 89 229 46 196617 change~;
#P newex 89 277 27 196617 ==~;
#P newex 108 254 49 196617 delay~ 1;
#N in 2;
#P newobj 188 49 25 196617 in 2;
#N out 1;
#P newobj 68 407 33 196617 out 1;
#N in 1;
#P newobj 92 30 25 196617 in 1;
#P newex 298 96 48 196617 loadbang;
#P flonum 356 214 64 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 298 121 98 196617 dspstate~;
#P newex 112 313 55 196617 delay~ 64;
#P newex 68 312 31 196617 sah~;
#P newex 111 82 45 196617 sig~ $3;
#P newex 111 110 68 196617 tapin~ $1;
#P newex 68 380 55 196617 snapshot~;
#P newex 112 339 36 196617 edge~;
#P newex 111 143 71 196617 tapout~ $2;
#P fasten 0 0 5 0 116 179 73 179;
#P connect 5 0 2 0;
#P connect 1 0 2 0;
#P connect 2 0 11 0;
#P fasten 19 0 15 0 212 219 94 219;
#P connect 15 0 14 0;
#P connect 14 0 5 1;
#P connect 10 0 18 0;
#P connect 13 0 14 1;
#P connect 15 0 13 0;
#P connect 18 1 4 0;
#P connect 4 0 3 0;
#P fasten 12 0 0 0 193 136 116 136;
#P connect 3 0 0 0;
#P connect 14 0 6 0;
#P connect 6 0 1 0;
#P fasten 8 0 13 1 361 241 152 241;
#P fasten 8 0 16 0 361 284 162 284;
#P connect 16 0 6 1;
#P fasten 18 0 17 0 97 76 212 76;
#P connect 17 0 20 0;
#P connect 20 0 19 0;
#P connect 9 0 7 0;
#P connect 7 2 8 0;
#P pop;


jbm
Feb 27 2006 | 12:44 am

hmm… that looks pretty good!

I’ll give it a try tomorrow… it’s almost 1:00 am here in the UK.

cheers, and thanks for the effort.

J.

[ps — I think I’ve actually learned a lot from this discussion, too. Your original patch, and the fix you made seem clear to me. So thanks for the MSP lesson! Don’t know why I’m so bad with MSP, but it’s starting to come clearer. Many thanks.]

Feb 28 2006 | 9:15 pm

jbmaxwell wrote:
> …expanding on this a little.
>
> if anybody has any brilliant insights on that, maybe you
> could just throw in your 2 cents about that?
>
> Or, coming at it from another angle, is it possible to create a
> bang-triggered snapshot in mxj or mxj~? Topher? Wes? Owen?

but snapshot~ is bang triggered if you do not give it an argument…
(my 2 cents, though not too brilliant ;-)

Stefan

[][] [][][] [][] [][][]
[][][][][][][][][][][][][][][]

Stefan Tiedje
Klanggestalter
Electronic Composition
&
Improvisation

/~~~~~
\ /|() ()|
))))) )| | |( \
/// _/)/ )))))
___/ ///

————————-x—-
–_____———–|———–
–(_|_ —-|—–|—–()—-
— _|_)—-|—–()———–
———-()————x—–

14, Av. Pr. Franklin Roosevelt,
94320 Thiais, France
Phone at CCMIX +33-1-49 77 51 72


jbm
Feb 28 2006 | 9:26 pm

yeah, sorry about that… I realized that looking at one of the examples someone gave me. I never actually read the help or Doc carefully enough to see that. gulp. I hate doing that… :-|

Anyway, I did tweak my previous pipe~ like object a little, and it’s working pretty well. I’ve also had some success in breaking apart my app by building a standalone to act as a sort of server. I’m using otudp/OSC so far, since the mxj net objects seemed to be producing lots of problems… not sure why. Right now it’s just my sample search process that’s in a standalone, and it seems to be working okay. I’m not sure how far I should go with this idea, but it’s kind of cool to know that it’s a possibility.

cheers,

J.

Viewing 23 posts - 1 through 23 (of 23 total)

Forums > MaxMSP