jhaysonn

AM I GOING CRAZY? the message is formatted correctly, right?

also, shouldn't the 'compressed' copy be the default?

AM I GOING CRAZY?  the message is formatted correctly, right?

also, shouldn't the 'compressed' copy be the default?


losing-mind-using-line

try the below instead. not sure why sprintf isn't working, but I guess it has something to do with the "," character... all "," is doing in a message box is delineate it into two lists; what comes before and what comes after. Maybe when you put it in with sprintf (,) some voodoo happens and the two lists aren't sent separately??? Don't know, sure someone will chime in who does ;) 

thanks for the help!! You have no idea how rare, and delightful, it is to post a question that ISN'T me just having a brain fart =)

thanks for the help!!  You have no idea how rare, and delightful, it is to post a question that ISN'T me just having a brain fart =)


ok - before you write me off..... here's an exmple of a brain fart.

1 - I feel it's not the most efficient way to do this.

By 'work' I mean draws a line from a->b and then goes from b->c.

ok - before you write me off..... here's an exmple of a brain fart.  

1 - I feel it's not the most efficient way to do this.
2 - it only works 'sometimes'

By 'work' I mean draws a line from a->b and then goes from b->c.


you have each side triggered by the end of the other side. on the blue side of things you bang the random 3000 then the random 100 into the 2nd and 3rd inlets of your pack. but then you replace the input to the 2nd inlet of pack with a different number. why? 

I haven't looked at anything other than the original patch in this thread, but you aren't understanding the role of the comma in a message box. This is sort of a shorthand that says chop this into two lists. In this example, it's exactly like sending an int, then a list of two items. It's the message box that interprets the comma, and sends two lists. You might as well send the two things yourself:

@MIB - I just noticed I was grabbing the wrong number in going from green to blue. BUT! your question: I wanted the 'B' point in the green section to become the 'A' point of the blue section. Then the end value of the line is the beginning of the next. If I were to just take the number generated directly from the green [pack] would output all it's integers (leftmost inlet). So I just needed something to hold on to ONE number until I could bang it when the green ramp was done. I know there is an object designed to do that...but all I could think of was one bang and this seemed to make sense using pack.

@Chris - MIB suggested doing it that way and clarified for me my misunderstanding of using the comma. But I'm still fuzzy on that since list works with (50,100 1500) as a message but not ($1, $2 $3) as one that, in the max window, is formated in the exact same way. List gets 50, then 100 1500 and works, but gets $1, then $2 $3 and doesn't. I understand how the comma breaks it up now, but am still confused about that.

INT!! THAT'S what I wanted to use. still doesn't help. =/

@MIB - I just noticed I was grabbing the wrong number in going from green to blue.  BUT!   your question:  I wanted the 'B' point in the green section to become the 'A' point of the blue section.  Then the end value of the line is the beginning of the next.  If I were to just take the number generated directly from the green [pack] would output all it's  integers (leftmost inlet).  So I just needed something to hold on to ONE number until I could bang it when the green ramp was done.  I know there is an object designed to do that...but all I could think of was one bang and this seemed to make sense using pack.

@Chris - MIB suggested doing it that way and clarified for me my misunderstanding of using the comma.  But I'm still fuzzy on that since list works with (50,100 1500) as a message but not ($1, $2 $3) as one that, in the max window, is formated in the exact same way.  List gets 50, then 100 1500  and works, but gets $1, then $2 $3 and doesn't.  I understand how the comma breaks it up now, but am still confused about that.  

INT!! THAT'S what I wanted to use.  still doesn't help. =/


So, it's probably time for you to state exactly what you want to happen. Line already starts from wherever it is, so maybe just sending destination time/value pairs is what you want?

forget about the initial single value (and comma when in message box): it is misleading-- all you need is a list of TWO ints destination, ramp, then regenerate a new list when the line is finished. line will remember its last value by itself

@ Chris - unbelievable. genius. wonderful and magnificent. Thank you.

@Terry - Thank you none the less for taking the time!

@ Chris - unbelievable.  genius.  wonderful and magnificent.   Thank you.  

@Terry - Thank you none the less for taking the time!


And just in case you want to understand what it would take to make your original approach work:

Ok... so I thought I had this figured out...but oh there's so many ways to go about things =/ I'm having a huge brain fart or I'm just not supposed to be thinking today.

that works GREAT for the pwindows. I can fine tune some numbers for in each iteration for the 12 different pwindows, fine. But I've randomized the start positions of those 12 windows. which means it's not just random expanding and contracting in an example; i need to utilize it's starting position. And I'm implementing their random movement around the patcher window using the 'presentation_rect' argument.

this is where I get super confused. Now obviously for the above problem the answer is in the [line] object and setting it's starting number...but I can't see it. I have two numbers for it's size I can't just use one for the starting point. I'm very confused about this.

thanks to anybody that can help out my foggy brain

Ok... so I thought I had this figured out...but oh there's so many ways to go about things =/  I'm having a huge brain fart or I'm just not supposed to be thinking today.

that works GREAT for the pwindows.  I can fine tune some numbers for in each iteration for the 12 different pwindows, fine.  But I've randomized the start positions of those 12 windows.  which means it's not just random expanding and contracting in an example; i need to utilize it's starting position.  And I'm implementing their random movement around the patcher window using the 'presentation_rect' argument.  

this is where I get super confused.  Now obviously for the above problem the answer is in the [line] object and setting it's starting number...but I can't see it.  I have two numbers for it's size I can't just use one for the starting point. I'm very confused about this. 

thanks to anybody that can help out my foggy brain


I'm really not sure what you're asking here.

OK, but what do you want it to do? Should the rect stay the same size and move around the window? Should it stay in the same position and grow and shrink?

both. I want to use performance_rect $1 $2 $3 $4 and manipulate it in every way. I had the $3 $4 but I'm stuck on how to introduce it's starting point.

the end goal is to have 12 [scissor]'d jit.pwindows gowing crazy in a patcher and then I am going to have an event line up and form it's coherent video.

both.  I want to use performance_rect $1 $2 $3 $4 and manipulate it in every way.  I had the $3 $4 but I'm stuck on how to introduce it's starting point.

the end goal is to have 12 [scissor]'d jit.pwindows gowing crazy in a patcher and then I am going to have an event line up and form it's coherent video.


Maybe this will push you in the right random direction:

ok, that makes perfect sense. I was hesitant to add all those randoms...because that's going to be multiplied 12x. Thank you so much. I apologize for the lame questions today! THANKS!

ok, that makes perfect sense.  I was hesitant to add all those randoms...because that's going to be multiplied 12x.  Thank you so much.  I apologize for the lame questions today!  THANKS!


From an efficiency POV, the randoms will be the least of your problems, I think.

hahahahaha, oi. yea I'm gonna go talk with my max professor from university when I'm nearing completion and poke around to get it as efficient as possible. alway been my biggest problem. thanks again man.

hahahahaha, oi.  yea I'm gonna go talk with my max professor from university when I'm nearing completion and poke around to get it as efficient as possible.  alway been my biggest problem.  thanks again man.


I had a lot of trouble with [line] too until I figured out that commas from [sprintf] seemed to confuse it. I use [t] to make sure that the new start position gets sent before the duration and destination pair are sent to it, or just send them without a start position if that is appropriate.

This thread has been a sanity check for me, they are going to let me out now.

The whole comma thing has proven confusing over the years. The thing to remember is that it is the message box that understands commas, and splits the lists into multiple messages. line itself knows nothing about commas.

hahaha, it is extensive. But I've learned a lot. Hopefully I can get something working today as the fog of yesterday is residing. I can't say thanks enough to you guys for taking the time.

...maybe the fog was my sanity leaving 0.o

hahaha, it is extensive.  But I've learned a lot.  Hopefully I can get something working today as the fog of yesterday is residing.  I can't say thanks enough to you guys for taking the time.

...maybe the fog was my sanity leaving 0.o


I noticed that my windows have no regard for these screen bounds. the in out is confusing but it I send the performance patch where these windows are flying around in a message 'window size 100 100 1280 720, window exec' into a thispatcher, then when it does the in out thing, it works. I get the right dimensions.

I thought at first that the 1280x720 parameters wouldn't be enough because the top most left pixel of the pwindow is where it's origin is right? so it could reach the bounds and we'd never see it. so I added the [- 100] which only seemed to make things worse. in any event the windows fly WAY out of the 1280 720 window I have for it. Should I send the [thispatcher] a 'window constrain 100 100 1280 720, window exec' message as well? what exactly will this do?

Why wouldn't my lines understand that they are not allowed to go beyond certain points?

I noticed that my windows have no regard for these screen bounds.  the in out is confusing but it I send the performance patch where these windows are flying around in a message 'window size 100 100 1280 720, window exec' into a thispatcher, then when it does the in out thing, it works.  I get the right dimensions.  

I thought at first that the 1280x720 parameters wouldn't be enough because the top most left pixel of the pwindow is where it's origin is right?  so it could reach the bounds and we'd never see it.  so I added the [- 100] which only seemed to make things worse.  in any event the windows fly WAY out of the 1280 720 window I have for it.  Should I send the [thispatcher] a 'window constrain 100 100 1280 720, window exec' message as well?  what exactly will this do?  

Why wouldn't my lines understand that they are not allowed to go beyond certain points?


I did think to take out the 100 100 that is beeing sent to my [scale] objects that generate x/y coordinates and I noticed it did help keep things from straying to the bottom right, but they still have little regard for my screen real estate.

really curious what constrain does but I don't want thispatcher to eat my patch again...

I did think to take out the 100 100 that is beeing sent to my [scale] objects that generate x/y coordinates and I noticed it did help keep things from straying to the bottom right, but they still have little regard for my screen real estate.  

really curious what constrain does but I don't want thispatcher to eat my patch again...


lol, it's a bit crazy. But I think I finally got it. i hope 0.o haven't worked on that patch in a bit - something stole my attention!

ps - still can't keep those pwindows inside the patcher =,(

lol, it's a bit crazy.  But I think I finally got it.  i hope 0.o  haven't worked on that patch in a bit - something stole my attention!

ps - still can't keep those pwindows inside the patcher =,(


losing mind - using line