[Maxmsp] 物件備忘錄

scale - Map an input range of values to an output range

scale a b c d : 將a~ab的值作比例轉換至c~d間
The scale object will perform in exponential mode when a fifth argument is specified. This fifth argument must  be greater than 1.0 or the output will be linear.
hi and lo values can be reversed for inverse mapping!

itoa / atoi - integer to ASCII / ASCII to integer
coll - Store and edit a collection of different messages

coll allows for the storage, organization, editing, and retrieval of different messages.

PING))) ultrasonic sensor + Arduino + Maxmsp

PING))) ultrasonic sensor的腳位為 SIG , 5V , GND

此種超聲波感測器的特殊點為使用的是Digital Pin

Arduino程式部分已有寫好的預設範本，還可實際的換算出距離(英吋或公分)

[MAXMSP] 常用熱鍵&優化運作

操作技巧
連結connection時, 按住shift可以多次連接
Alt+Drag 可以框選patch cords
Ctrl+D可以重複位移複製
雙擊(unlock時要+Ctrl)save, receive, value物件會列出關係物件以供找尋位置
m 新增message
n 新增object
j 新增jitter
i 新增int
f 新增float
b 新增bang
t 新增toogle
c 新增comment
r 開啟Recent列表
ctrl+E 切換lock/unlock


Improve displays performance

Anytime you are using a jit.pwindow object which is smaller than the video being displayed (here, our video is 320x240, and our jit.pwindow is 80x60), you should turn off onscreen mode. It's a simple rule that will get the best possible speed from your performance patch.

Onscreen and offscreen modes use different drawing algorithms to do their work—data is drawn directly to the display in onscreen mode, while offscreen mode draws the data first to an offscreen buffer and then copies it to the display. The algorithm used in onscreen mode doesn't favor downsampling, so the performance is not as good.

Optimize your patch

http://abstrakt.vade.info/

 Some basic guidelines for any programming environment:

• Get it working before you optimize - no need to complicate your life ahead of time

• Clean, commented, organized code is easier to understand, and easier to optimize than messy, uncommented code - especially with graphical patching environments, messy means visually complex, hard to follow patchcoord everywhere spaghetti. Not fun.

• Test your code - isolate potential bottlenecks and try out various methods. Sometimes more code can be faster than less, in specific cases (compare the amount of objects for the gpu based uyvy playback patch to the CPU based one) .

For Jitter specifically, some considerations - and DO NOTs.

• DO NOT create unnecessary UI objects that constantly update - Jitter shares its drawing thread with the Max UI - the more you draw on screen, the less time Jitter has to draw to your window. If you REALLY need all that stuff on your screen blinking, set the screen refresh rate lower in performance options - and use qlim to limit the rate of updating.

• No really, DO NOT create unnecessary UI elements, even hidden ones. Max has to keep track of them. Simply hiding them wont do it. Replace number boxes with [float] and [int], etc.

• Pwindows - those little preview windows everyone wants to use - use qlim to limit the speed the pwindow is updated, and turn off “Use Onscreen” - you should see a decent speed increase just from that.

• If you are using OpenGL, it is highly recommended to manage drawing manually by using @layer, or with @automatic. Using @automatic 0 allows you to stop OpenGL objects from drawing/being activated by simply not banging them. This can be very useful with complex filterchains. Its a pain at first, but manageable and much more powerful

• If you plan on using the UYVY colormode, it is suggested you use the cc.uyvy2rgba shaders, as Windows users do not have native UYVY texturing (at least, @colormode on some GL objects in XP does not work). Just a heads up