how to pack values for a [line] msg?
hey...
i want to use a line object to play through a sample file...
i know that line needs a msg with three values
(startpoint, endpoint duration)
lets say i want these values generated randomly...
how do i have to pack those values that the msg will be set up properly?
[pack $1 $2 $3] -> ($1, $2 $3) -> [line] ?
thanks
i use this [sprintf %f, %f %f]
:awaits method that uses 60% less resources:
do the below
'NEVER do this' haha
answer me this pid. i have a granular patch with absolutely tonnes of these things going off all the time, continuously, and it runs like clockwork. so where is this 'ever growing amount of resources' actually going? just checking activity monitor for max, all values are constant and don't seem to be increasing at all.
now i'm not saying you're wrong, as i don't know the ins and outs of Max's symbol tables and the like, but for every 'no don't do this' post i usually find i'm doing exactly that, with no problems at all.
enlighten me :)
oh, maybe ignore me then - i have no great way to 'enlighten' when max says one thing and we have to try figure out the other. wait till someone cleverer posts...
The efficiency of sprintf depends on what you're doing with it. Every unique symbol in max is stored in RAM, and never free-ed until you close max. So if you're using it for general formatting of input values, you're likely going to be adding a large number of unique symbols to RAM, which in theory could begin to waste your memory resources - I don't know if this applies in the same way to floats and integers.............If you're using it for message parsing to grab file names or something similar, it's a more appropriate object to use because you won't be generating symbols very often.
So for general purpose things like formatting for line/line~ it's not the best object to use.
-edit: With sprintf, if you're using it to format the same things over and over, then it doesn't really matter that it's storing into RAM, as you'll be replacing the same symbols over and over, not adding to it. The reason it does this is to speed up processing of things if done a second time, so in MikeS's patch, it might be totally appropriate, if it's not causing problems then why change it :) That's not to say that there aren't multiple ways of doing just about everything in max/msp, none of them are "best" in every situation. -
Since coffencigs is wanting to control audio playback, line~ is far more appropriate to use than line. You want to be controlling audio-rate processes at audio rate most of the time, or you'll end up with clicks and glitches.
The pack>message>line~ method is a perfectly good way of doing it; simple and it works. If you want to be really pedantic, you could say that it's inefficient because the message object will have to visually refresh often, wasting resources. However this is not something to worry about unless you start running into cpu-limits. I think also, that if you put it in a sub-patch/made it not visible in some other way, then it being a GUI object wouldn't matter, as it wouldn't have to refresh.
My advice is to just use pack>message>line~ and not think about all these little worries until you think they might be causing a problem, which is unlikely to happen. If you don't like message, you could do it like this:
you can not do it with pack, because you need "float, float float"
i usually put a [t l 0] between my lists and line
-110
Maybe I'm misreading your post Roman, but are you saying that pack doesn't work with floats?
It works with pack and floats :) I'm not sure why you need a [t l 0] before line? That would truncate any input floats to int.
usually you want to set a line before starting it, right?
maybe i am mistaken, but when i hear something about "line format" i am
thinking of the MSP line~ object, where "float, float float" would the normal
way to trigger it.
and consecutive messages are not to be packed into a list ;)
I've overlooked the fact that [message] will screw with the comma. You need to do it like my example, which I think is pretty much what Roman was suggesting as well. Sorry for the confusion :)
Cheers for clearing that up Raja - I thought it would work!..............I mis-understood Roman's reply and double-checked the ($1, $2 $3) way with it outputting to the right inlet of another message, which of course screwed with the comma - making me think it wouldn't work with line/line~................I'm silly :)
How does this [t l 0] method work?
It works the same way as my example in my first post, except you're always sending a value of 0 as a start value for line, while my example has a variable start value.
gotcha, i'll see what difference it makes to my patch
another solution;
The comma in a message box is just shorthand for separating things. In the discussed case of line~, it is used to send an 0, followed by a list of value time pairs. This is no different from starting your list of pairs with 0 0.
This method just uses append.
{
"patcher" : {
"fileversion" : 1,
"appversion" : {
"major" : 7,
"minor" : 1,
"revision" : 0,
"architecture" : "x86",
"modernui" : 1
}
,
"rect" : [ 449.0, 149.0, 640.0, 480.0 ],
"bglocked" : 0,
"openinpresentation" : 0,
"default_fontsize" : 12.0,
"default_fontface" : 0,
"default_fontname" : "Arial",
"gridonopen" : 1,
"gridsize" : [ 15.0, 15.0 ],
"gridsnaponopen" : 1,
"objectsnaponopen" : 1,
"statusbarvisible" : 2,
"toolbarvisible" : 1,
"lefttoolbarpinned" : 0,
"toptoolbarpinned" : 0,
"righttoolbarpinned" : 0,
"bottomtoolbarpinned" : 0,
"toolbars_unpinned_last_save" : 0,
"tallnewobj" : 0,
"boxanimatetime" : 200,
"enablehscroll" : 1,
"enablevscroll" : 1,
"devicewidth" : 0.0,
"description" : "",
"digest" : "",
"tags" : "",
"style" : "",
"subpatcher_template" : "",
"boxes" : [ {
"box" : {
"id" : "obj-15",
"maxclass" : "message",
"numinlets" : 2,
"numoutlets" : 1,
"outlettype" : [ "" ],
"patching_rect" : [ 236.0, 136.0, 37.0, 22.0 ],
"style" : "",
"text" : "1000"
}
}
, {
"box" : {
"id" : "obj-13",
"maxclass" : "button",
"numinlets" : 1,
"numoutlets" : 1,
"outlettype" : [ "bang" ],
"patching_rect" : [ 174.25, 110.0, 24.0, 24.0 ],
"style" : ""
}
}
, {
"box" : {
"id" : "obj-11",
"maxclass" : "message",
"numinlets" : 2,
"numoutlets" : 1,
"outlettype" : [ "" ],
"patching_rect" : [ 204.5, 136.0, 31.0, 22.0 ],
"style" : "",
"text" : "100"
}
}
, {
"box" : {
"id" : "obj-9",
"maxclass" : "message",
"numinlets" : 2,
"numoutlets" : 1,
"outlettype" : [ "" ],
"patching_rect" : [ 177.0, 208.0, 89.0, 22.0 ],
"style" : "",
"text" : "10, 100 1000"
}
}
, {
"box" : {
"id" : "obj-7",
"maxclass" : "newobj",
"numinlets" : 4,
"numoutlets" : 1,
"outlettype" : [ "" ],
"patching_rect" : [ 177.0, 184.0, 91.0, 22.0 ],
"style" : "",
"text" : "pack 0 sym 0 0"
}
}
, {
"box" : {
"id" : "obj-6",
"maxclass" : "message",
"numinlets" : 2,
"numoutlets" : 1,
"outlettype" : [ "" ],
"patching_rect" : [ 174.25, 136.0, 29.5, 22.0 ],
"style" : "",
"text" : "10"
}
}
, {
"box" : {
"id" : "obj-4",
"maxclass" : "newobj",
"numinlets" : 1,
"numoutlets" : 1,
"outlettype" : [ "" ],
"patching_rect" : [ 177.0, 160.0, 57.0, 22.0 ],
"style" : "",
"text" : "append \\,"
}
}
],
"lines" : [ {
"patchline" : {
"destination" : [ "obj-7", 2 ],
"disabled" : 0,
"hidden" : 0,
"source" : [ "obj-11", 0 ]
}
}
, {
"patchline" : {
"destination" : [ "obj-11", 0 ],
"disabled" : 0,
"hidden" : 0,
"source" : [ "obj-13", 0 ]
}
}
, {
"patchline" : {
"destination" : [ "obj-15", 0 ],
"disabled" : 0,
"hidden" : 0,
"source" : [ "obj-13", 0 ]
}
}
, {
"patchline" : {
"destination" : [ "obj-6", 0 ],
"disabled" : 0,
"hidden" : 0,
"source" : [ "obj-13", 0 ]
}
}
, {
"patchline" : {
"destination" : [ "obj-7", 3 ],
"disabled" : 0,
"hidden" : 0,
"source" : [ "obj-15", 0 ]
}
}
, {
"patchline" : {
"destination" : [ "obj-7", 0 ],
"disabled" : 0,
"hidden" : 0,
"source" : [ "obj-4", 0 ]
}
}
, {
"patchline" : {
"destination" : [ "obj-4", 0 ],
"disabled" : 0,
"hidden" : 0,
"source" : [ "obj-6", 0 ]
}
}
, {
"patchline" : {
"destination" : [ "obj-9", 1 ],
"disabled" : 0,
"hidden" : 0,
"source" : [ "obj-7", 0 ]
}
}
],
"dependency_cache" : [ ],
"autosave" : 0
}
}