このページは管理者にのみ表示されます。

アクセスするにはサインインしてください。

このページはサインインしたユーザにのみ表示されます。

このページが誤って表示されていると思われる場合は、 <link>support@cycling74.com</link> にお問い合わせください。

このページを表示する権限がありません。

投稿の読み込みに失敗しました。

アクティビティがありません。

アクティビティ

{ name } のお支払い履歴

ライセンス

アドオンの削除中に問題が発生しました。もう一度お試しください。

アドオン<name>{addonName}</name> を本当にMaxサブスクリプションから削除しますか？ お客様の{addonName} アドオン・ライセンスは、現在のお支払いサイクルが終わるまで有効です。

{name} はお客様のMaxサブスクリプションから正常に削除されました。

アドオンを削除する

サブスクリプションを再開する際に問題が発生しました。もう一度やり直してください。

アドオン<name>{addonName}</name> を本当に再開しますか？ お客様のお支払いサイクルは再び有効化され、利用料は通常通り{renewalDate} に請求されます。

サブスクリプションが正常に再開しました。

サブスクリプションの再開

サブスクリプションのキャンセル中に問題が発生しました。

ライセンス<name>{licenseName}</name>を本当にキャンセルしますか？ お客様のライセンスは、サブスクリプションが期限切れとなりライセンスが無効化される<expiry>{expiryDate}</expiry>まで有効です。

サブスクリプションは正常にキャンセルされました。

サブスクリプションのキャンセル

次に、Maxアプリケーションを起動し、アカウントにサインインします (ヘルプ > ユーザー・アカウントとライセンス) 。

Maxが正常にアクティベートされました。

Maxをアクティベートするには、アカウントにサインインする必要があります。

Maxをアクティベートする

Create a New Post

Edit Article

The list of what we're discovering about Max and our users grows each day. We tackle everything from hardware reviews to re-reading books from decades past.

Get the Latest on Max and our Community

Articles

サインアウト

サインインしてライセンスをオーソライズする

Maxをオーソライズする

フォーマットで絞り込む

言語で絞り込む

Maxを学ぶための書籍を探す

Maxについての書籍

Here are the artists and educators helping people get creative in Max

Meet Our Max Certified Trainers

Certified Trainers

{ firstName } { lastName } - Certified Trainer

There are no open positions at this time.

このウェブサイトはCookieを使用しています。

予期しないエラーに遭遇しました。

詳細な手順については、受信トレイを確認してください。

パスワードを忘れた場合はこちら

エラー

成功しました

Actions

Create Forum Topic

Edit Forum Topic

{category} Forum

There was an error submitting your details. Please try again.

Thank you for your submission! Someone will be in touch with you soon.

NFR / Industry Accomodations

メールで受信したリンクを使用していることを確認してください。

招待の取得中に問題が発生しました。

あなたのアカウントは正常に作成されました。教育機関のライセンスを管理するには、 <authLink>https://auth.cycling74.com</authLink> にアクセスして、新しく作成したアカウントでサインインしてください。

このページを表示するにはサインアウトする必要があります。

アカウントを作成する

メンテナンス中

現在、当社のウェブサイトの定期メンテナンスを行っています。一部の機能は一時的に利用できません。ご理解のほどよろしくお願いいたします。

名前

並べ替え

{ category } Packages

Share a Max Project

Edit Project

Image Notes

Important Notes

Max Projects come in all shapes and forms. Over the years, our users have shared over a thousand ideas and projects with us. We're proud to showcase them here.

Find Inspiration from other Max Users

Cycling '74 will review it within a week and may make minor edits before publishing it, so your project looks best and reads well in our project gallery.

Thank you for your submission! Your project is currently pending.

アカウントが復元されました。

アカウントの復元

バンドル済み

{ name } { version } リリース・ノート

パスワードの変更中に問題が発生しました。もう一度やり直して下さい。

更新された登録情報にて <link>ログイン</link> できるようになりました。

パスワードが正常に変更されました。

パスワードをリセットする

あなたの購入はこのアカウントにリンクされました。Maxアプリケーションを起動し、アカウントにサインインしてください。（ヘルプ・メニュー＞ユーザー アカウントとライセンス）

ライセンスを取得する

種類

Cycling '74フォーラムとウェブサイトを検索する

{query} 検索

教育機関の詳細を入力してください

この購入には、Max for LiveまたはLive Suiteのシリアル番号が必要です。 <link>シリアル番号の確認をお手伝いしますか？</link>

サブスクリプションの更新中に問題が発生しました。もう一度やり直してください。問題が解決しない場合はsupport@cycling74.comまでお問い合わせください。

サブスクリプションのアドオンを確認する

ご購入ありがとうございます。

ありがとうございます。

ご注文の詳細情報を取得中です。お待ちください...

ご質問や問題がある場合は、 <link>support@cycling74.com</link> までお問い合わせください。

サインインできませんでした。ユーザー名/メールアドレスとパスワードが正しいことをご確認ください。

Cycling '74のアカウントでサインインする

アカウントの作成中に問題が発生しました。もう一度やり直してください。

ユーザーアカウントが正常に作成されました。最後の確認手順については、メールをご覧ください。

Cycling '74のアカウントを作成する

製品を選択する

ありがとうございます。リクエストがサポート・チームに送信されました。メールをご確認ください。

There was an error sending your application. Please try again.

リクエストの送信中にエラーが発生しました。もう一度やり直してください。

このiLokリクエストを送信することにより、資産がiLok.comアカウントに預け入れられたときに通知されることに同意するものとします。通知を受け取った後、資産をiLok USBスティックに転送できます。すべてのiLokリクエストは手動で処理されるため、通常の営業時間（月曜～金曜、太平洋標準時の午前9時～午後5時）にリクエストを処理するのに最大48時間かかる場合があることにご注意ください。

重要なお知らせ

Thank you! Your request has been successfully submitted.

Please note that we are no longer taking submissions for Tools and no longer supporting the Tools section, so you may run into broken files and URLs. You can contribute to the Cycling '74 Community by submitting a Package or using the forums instead.

Max Tools Archive

Edit Tutorial

Tutorials are an ideal way to accomplish a task, learn a new strategy or brush up on your skills. In addition to our in-app Examples, Tutorials and Help Files, you can find new ones here.

Explore the Online Tutorials

Tutorials

ありがとうございます。Maxを起動し、ライセンスを使用するためにサインインしてください。

アップグレード

パスワードを忘れた場合

サインイン

アカウントの認証が必要です。

アカウントの確認が必要です。受信トレイをご確認の上、メールが届いていない場合は、<link>ここをクリックしてもう一度確認メールの送受信を行なってください</link>。

未認証アカウント

ここでMax 8をアクティベートする

アクティベーション・コードをお持ちですか？

既にMax 8を所有しており、オーソライズの準備ができていますか？

問題がある場合は <link>support@cycling74.com</link> までお問い合わせください。

Maxを初めて使用する場合、これはまさにあなたのためのものです。

アカウントを認証していただき、ありがとうございます！

Cycling '74コミュニティの一員になるために、あと一歩です。

Cycling '74アカウントを認証する

新しい認証メールのリクエストに失敗しました: {message}

認証メールが { email } に送信されました。受信トレイをご確認ください。

認証用のメールが見つからないか、期限切れのメールだけが見つかる状態ですか？

メールアドレスの変更を確認中に問題が発生しました。もう一度やり直してください。

メールアドレスの認証中にエラーが発生しました。

メールアドレスが正常に認証されました。ありがとうございます！

メールアドレスを認証してください。

メールアドレスを認証するにはユーザー・トークンが必要です。メールで受信したリンクに従ってください。

R_Gol

This is an idea to develop and I wonder how to implement this.

I have data from two users touching and moving hand on sensor. 

In this patch I have a default range of 30 that only if users are inside that range a sound is playing.

I would like to make the range adaptable based on some conditions.

user can choose time windows to look at and increment/decrement  steps 

time window set to 2 sec - increment/decrement step set to 3.

if user are within range  in the 2 sec window, another 2 sec window start - if they pass the second window then range is reduced to 27. if they continue to hold together inside the range for another 2 second and another 2 second - range is reduced by another 3. if not (users went out of range) then range is increased by 3.   

so in order to reduced range user should manage to be inside 2x window time while to increase range used should be out of window only for 1 window time.

This is an idea to develop and I wonder how to implement this.

I have data from two users touching and moving hand on sensor. 

x y and...

adaptive-range-based-on-some-parameters

adaptive range based on some parameters

Shane

This seems like it should be super simple, and it probably is...

I'm looking for a way to read a movie into jit.movie IF it is present in a specified location, or ELSE to prompt the user to specify the location (just like if you pass the message "read" with no filename attached).

I'd be very grateful for any tips! And apologies for the noob question...

read file into jit.movie (if present) OR prompt user for location

read-file-into-jitmovie-if-present-or-prompt-user-for-location

broc

With recent tests I've noticed that the latency of send/receive seems related to Live's audio buffer size.

So in contrast to earlier versions, there is no jitter and the latency seems predictable to some degree.

Can this result be confirmed by the developers?

latency-of-sendreceive-predictable

I've repeated the test with another setup and this time found latency near 0!
Apparently it depend somehow on the setup, in short: the latency is basically *not* predictable.

The question remains if the *maximal* latency is predictable, ie. determined by the audio buffer.


hey broc, what was your setup for the second test? (sorry for quasi thread hijack).

p.s. - i want answers to all broc's questions too.


My second test was minimal.
No audio track, just 2 MIDI tracks with M4L MIDI effect on each for sending a bang and receiving it.
Time measurement with [cpuclock].

I guess the 0 latency was achieved because in this case both tracks did run on the same thread.
But the behavior may be difficult to reproduce depending on other unknown factors.

Are there any other info about send~ and receive~'s latency?

I just realized this latency by playing my double bass through Max and comparing with and without send~/receive~. The latency is pretty obvious to my ears without any measurement.
This is weird because I've been playing my bass through Max for 6 years and didn't really notice anything. I always have exactly the same settings that I loadbang. 

Does this latency adds up if I have several chains of send~/receive~?

There should be a mention about that somewhere in the help file, reference or tutorials.
Florent


I think send~ receive~ pair have a latency of 1 signal vector, so if you have a large vector and a signal going through a number of these pairs you'll get a noticeable latency

it is always one vector, but if it properly works in live is another question.


thanks guys,
Ok, so theoretically the latency is one vector, but in practice it is not. Am I correct?
Broc's tests above show that it is not predictable and consistent.
Why? What does it depend on?


It is one vector when the signal chain that ends in a send~ has somewhere a receive~


there were similar issues in pluggo with logic, it might be that in live it also makes a difference if you are having 2 devices in different channels or in the same. and as you already found out, the buffer size seems to matter. :)


Hey, sorry if my question sounds stupid, but what is the math to calculate the length of a vector?

For example, if my sample rate is 44.1Khz, my I/O vector size is 64 and my signal vector size is 64, what is the duration of my send~/receive~ latency?
Just trying to figure out if the latency I hear comes from those send~/receive~ pairs or from something else.
thanks
Florent


@broc::
i`ve done a lot of testing some time ago,to me send/reveive had a latency of exactly 30ms.
but maybe this imrpoved by now...
anyway, i started using udpsend/receive which also has unpredictable
latencies but far shorter ones.
another issue regarding m4l is that the entire API is NOT IN ANY WAY
timing-accurate,there`s lots of jitter all over the place with up to 30msec.
which is ,@florent ghys, when the human ear stars to recognize an echo.


thanks RBRT for the feedback
what buffer size did you use for this 30ms tests?


I have arrived to clear up some confusion! >;D

Broc's original post is about send/receive('s'/'r'), the non-signal versions(note the mention of measuring receipt of 'bang').
(When RBRT is addressing Broc, he is making a suggestion about udp offering better latency than the non-signal versions.)
When FlorentGhys rebumped this thread 3 years later, he's now talking about send~/receive~ pairs, the signal-version(where the vector size, as mentioned by others, comes into play).

FlorentGhys can ignore RBRT's findings if he is more interested the latency of the signal-versions.

(...in regular max/MSP, send~/receive~ only added vector of latency when placed in feedback loop, so the pluggo/m4l thing is likely a protection for plugin-style operation...)

I am done now. You may return to your regularly scheduled programming.


Thanks, this is a very good clarification and I apologize for the confusion.


@RBRT
In my experience the latency and jitter of send/receive vs. udpsend/receive are basically the same where the maximum depends on Live's audio buffer size. I can confirm the general inaccuracy of API, even up to 50ms.

Anyway, it's a shame that the diverse latency issues of M4L are not clearly explained in the documentation.


I USED TO BE RIGHT.NOW I M ALL WRONG.
i just did the latency-test again,with max 6.1.9 and live 9.1.5.
there is NO latency with send/receive from one M4L-device to the other anymore.seems someone has fixed this.
I ' m very very sure it used to be 30msec.maybe I should also check the LOM for latencies again..
bye bye udpsend, hello send/reveive.


Interesting. What was your setup for the latency test?
Did you try sender and receiver on the same track or different tracks?


hit hitme..i hope the rest is self-explanatory..


I tried your test (on Live8, Max5) and also got NO latency with send/receive.
Apparently the behaviour was changed already in earlier versions (see also my 2nd post on this thread).
But I still wonder if it's true for every possible configuration.

Any comment from the developers would be much appreciated.


What about sending signals between patches on the same track? Is there a way to compensate latency?
I tried sending from patch A to the immediately following patch B, and sending float has some latency, as well as sending audio. I tried using a third patch, because maybe the sending from A and B have the same latency when reaching C, but it didn't work, they have different as far as I can tell.
I also tried sending the signal (instead the float) form A to B, then delaying patch B's own signal, but it seem to me that the delay~ can only delay a signal by 512 samples, which is weird.
I'm a beginner, so any info or clearing things up in my head is appreciated.


@WINGEDFINGER: hmm I cant reproduce with my patch regarding the float...I am not talking about audio here in general,only about messages.audio will have some sort of delay and I dont think that
can be changed..
did U use the patch I set up?
@BROC: I just checked about LIVE's API again,and it seems somebody has been working on it.I get
only 10 msec of delay now for starting LIVE's transport from M4L.this used to be 30 msec.
I totally agree with you that timing inaccuracies intoduced by the LOM should be documented..

Hey there, in order to have one midi track sending midi notes to several „layer children tracks“ with instruments on them,  I am using s/r. The “Master“ track has a send device on it (midiin —> s chan1) and the midi tracks with the instruments each have a recieve device on them (s chan1 —> midiout).
When starting the clip on the “master“ track and havin abletons metronom playing aswell, the instrument tracks are randomly off grid/quantisation of the metronom (getting randomly long delayed, due to latency I guess).

I am using Ableton Live 10.
Is there any way known by now, to get rid of the latency issues, when using  s/r over multiple tracks?

it's a pity to hear this issue still hasn't been taken care of in Live10/Max8.
from what i remember (i think by reading posts on this thread some time ago), it's not advisable to use send/receive for routing audio/midi in maxforlive unless you really don't care about timing issues.
in your case, i would suggest to use LOM messages for the routing instead of S/R.




You know that you can address other tracks from M4L in Live 10 now correct, both audio and midi. 

@Malte I am actually getting super good results in the exact same situation. Do you have a small buffer size in your preferences? M4L runs in audio in interrupt so you better have a small i/o buffer size

there is also an easy workaround if you want to bypass Max's send and receive objects: use Ableton's built-in routings in which all your "children" tracks receive from the main track. Then from your main track assign a midi value such as pitch bend, cc, program change... to each midi note with the midiformat object, and then on your children track, unpack and select. Something like this: 

Cycling '74 Forum