Guillaume Evrard

OSCKAR is a tool that allows you to quickly use data coming from various hardware devices and network (HI, MIDI, Wacom, Keyboard, OSC, other messages) inside your own patches. It's developed for La Grande Fabrique, Dieppe, France.

OSCKAR generate an unique symbol referencing each incoming data. This unique symbol is OSC formatted (but not used as OSC yet).

examples :/MPK_Mini/1/ctl/1 would be control 1 on channel 1 of my Akai MPK Mini./MPK_Mini/1/notes would provide a list [pitch velocity] from channel 1 of the MPK Mini.

OSCKAR can also generate new data, re-use them in virtual devices, and share them over the network with other OSCKARs.

then, OSCKAR provide an virtual device builder, this allows you to aggregate data from different controllers to build your own virtual device. When building a virtual device you can choose as many data as you want, define scale and smooth settings for each of them, and rename them to have a human readable list of controls.

note : you can't use twice the same control in a virtual device, but you can use the same control in different virtual devices, with different scale and smooth settings.

3 - OK, I have built my virtual device, how do i use it ?

Once you're done building your device, just use the [osk.r] abstraction to access data from your patches. See the help file of osk.r for a complete description, or just double-click it to easily map a data.

OSCKAR comes with a template "instrument" (it's a patch OSCKAR can communicate with).

4 - Hey I've developed many instruments using your great tool. But it's a pain to activate/deactivate them !

No problemo ! OSCKAR has been designed to help you switching instruments on-the-fly !

With what I called "scenes" you can build an instruments bank, navigate inside your bank, and choose to activate/deactivate what you want. And these operations can be mapped on controls coming from your devices ! No need to touch your computer when playing live !

- OSCKAR is still under high development and the specifications are subject to change, but I'd be glad to have some feedback from some maxers at this point.
- A more complete user guide should be written within some weeks.
- Virtual devices are NOT cross-platform.


osckar

OSCKAR

leico

I hope you to use it with your great/crazy/smart idea.

エクスターナルオブジェクトを作りました。

後はみなさんが煮るなり焼くなりして下さい。

ray-sniff-record-our-web-field

ray.sniff~ convert our web field

Rodrigo

dfscore was originally built in Max (although the current version was rebuilt in javascript to function completely in a web-browser).

dfscore-2-0

dfscore 2.0

Ben Nevile

In order to maximize the potential of the built-in networking classes that are new with version 4.5 of Max, it's helpful to understand a few things about the way that modern network protocols operate. This article is intended to help you get off the ground by answering some basic networking questions.

Q: What are the differences between the net.maxhole, net.udp.*, net.multi.* and net.tcp.* classes?


Which of the above classes to choose depends on your application. All of them are based on either UDP or TCP, the two dominant protocols that computers use to communicate in today's networks. To communicate with the internet these protocols both use what is called the IP (Internet Protocol) layer, which is why you sometimes see acronyms like TCP/IP.

UDP (User Datagram Protocol) is the simpler of the two protocols. To send data via UDP, all that's required is a destination port and IP address. When using UDP your data is wrapped into a packet with a header that, among other things, contains the packet's destination address. UDP does not provide any feedback on the status of the packet after it has been sent, so if for some reason the packet can't be delivered to the destination - the internet goes down, someone trips over a network cable, the receiving computer isn't listening on the proper port, etc - the application that sent the packet will never know. Furthermore, UDP provides no guarantee that the packets you send to another host will arrive in the order that they were sent. If there is a single, well-defined route between the computers the probability of packets arriving out-of-order is close to zero. When data is being transmitted over the internet, however, different packets can take different routes to the same destination, and consequently the probability of UDP packets arriving out-of-order is high. The higher your rate of transmission, the higher your probability that packets will arrive out-of-order.

Like UDP, TCP (Transmission Control Protocol) sends data in packets. However, extra information is embedded in the packet headers to help the protocol track the packets it has sent. When a computer receives a TCP packet it sends back a small ACK (acknowledgement) message which includes a packet ID. This allows TCP to track which packets have been received successfully by the remote computer. If the sender does not receive an ACK within a certain time the packet is re-sent. Because each packet is labelled chronologically, the TCP implementation on the receiving computer is able to sort the incoming packets into the proper order even if they were received out-of-order.

These differences between the protocols are evident in an examination of the Max objects provided with v4.5 for use with the mxj Java object. net.udp.send has an inlet to take data to send to the specified address and port, but no outlets that report back on the status of the packets. net.tcp.send on the other hand has three outlets that report on the status of the data you've input to be sent: one outlet reports what data was sent successfully, another reports what data was not sent successfully, and a third outlet reports the number of packets that are still "in limbo" - that is, no acknowledgement of their successful transmission has been received, but the algorithm hasn't given up on them yet.

To make the back-and-forth communication between TCP hosts possible, the protocol requires that a connection be made between the two computers prior to sending any data. No such connection is required with UDP. Having to make this connection causes a delay before any data can be sent. The time delay is roughly equivalent to the RTT (round trip time) that it takes a packet to reach the destination and come back. For applications sending a lot of data the cost of this connection is mortgaged over the time it takes to send all of the data, and therefore is usually negligible.  Currently with net.tcp.send and net.tcp.recv, the TCP connection is created and destroyed for each new piece of input data to be sent, similar to HTTP. This results in less efficient transfer of data, but allows for one net.tcp.recv object to receive data from multiple clients. In a future version the object may allow a TCP connection to remain intact between data transfers. Some examples of common applications that use TCP are SMTP (email), Telnet (remote login), FTP (file transfer) and HTTP (the www). Some examples of applications that use UDP are DHCP (bootstrap IP protocol), NTP (network time protocol) and Traceroute.

net.maxhole was built in order to make simple network commmunication as easy as possible. Simply instantiating net.maxhole objects in the default form allows instant networked communication without having to think about IP addresses, ports, or protocols. net.maxhole uses multicasting, which is just a UDP transmission to a special kind of IP address that every computer will receive. So whereas with regular UDP you specify a single receiver and the packet is intelligently routed to just that one machine, with a multicast address the routers send the packet to every computer. The range of a multicast packet is controlled by a special piece of data called the time to live that exists in every IP packet header: every time the packet is received by a router, the time to live is decreased by one, and when the time to live reaches zero, the packet is destroyed. For net.maxhole the time to live is 1, so it will only be passed through a single router to other machines in your local network. For more adventurous multicasting, the net.multi.send implementation of the multicasting protocol allows you to set the time to live via the "maxhops" attribute. An example of a system that uses multicasting is Apple's Rendezvous service-discovery technology (which other organizations call ZeroConf.)

In summary, if your networking demands are modest the easiest object to use is net.maxhole. It should be appropriate for most small local network situations you can throw at it. If communication latency and throughput is of utmost importance, and you don't want to multicast to all the machines on the network, then UDP is worth investigating. If reliability is important, then using TCP is recommended.

Q: How can I send and receive data through a router's firewall?

When thinking about networking it is useful to think in terms of clients and servers. A server process sits and waits for a connection on a port, and a client process initiates the communication to the server. In terms of the Max networking classes, net.tcp.recv is a server, and net.tcp.send is a client. A connection between a client and a server has four important pieces of data: the server's IP, the server's port, the client's IP and the client's port.

TCP and UDP both define a group of well-known ports to identify well-known services: FTP is 21, HTTP is 80, etc. Well-known ports tend to live in the range between 0 and 1024. Clients, however, use ephemeral, or short-lived ports. These port numbers - which typically range between 49152 and 65535, depending on the OS - are automatically assigned to a client by the UDP and TCP code that lives in the operating system's kernel. UDP and TCP guarantee the uniqueness of the ephemeral ports they assign, which prevents conflicts in communication between different client processes. This scheme is what allows your computer to have more than one active FTP session going, or be able to download web pages from more than one site at the same time.

A server that wants to simultaneously handle more than one process also needs to use its own ephemeral ports to create connections so that it can keep listening for connection requests on its well-known port. For example, if you make a FTP request to 142.34.56.222:21 from 145.35.52.65:57474, the server may request that the connection be made on port number 50423 instead of 21. ie, the final connection would be between 142.34.56.222:50423 and 145.35.52.65:57474.

Local area network routers add more complication. To the outside world all the computers behind the router have the same IP address, so the router must distribute all incoming packets based on the port. The complication is that each computer controls its own ephemeral ports, and so there is the potential for conflict. For instance, if two computers behind the same firewall both request FTP sessions with outside sources, there is nothing preventing both of the computers from assigning port 50000 to the request.

The solution, which is called NAT (Network Address Translation), ensures that there is no conflict between ports by changing the outgoing port numbers without any of the computers knowing about it. When a router sees a new outgoing request it changes the ephemeral port number for the client computer to a new port number from a table maintained by the router. The remote server returns the request to the port that the router set up, and then before passing the data back to the client computer the router changes the port back to the number that the client is expecting.

Most routers have a built-in firewall that stops incoming data before it reaches computers on the local area network. Usually the router provides a method of configuring the firewall so that an administrator can decide which ports should be open and closed, and which computers in the LAN should receive the data sent to the open ports. When initiating a TCP connection from a client within the LAN to a server outside the firewall it should not be necessary to explicitly configure the firewall since the router will adjust the firewall's rules to appropriately pass data. UDP, however, is a connectionless protocol, so to receive or send UDP packets through a router the port must be explicitly opened by an administrator.

max-networking-basics

Max Networking Basics

dfscore-dynamic-networked-score-system

dfscore - dynamic networked score system

Garrett

The work uses a combination of Max, MSP, Jitter and Java.

netscapes

Netscapes

Terence Caulkins

Cycling '74

SO-IL, Arup, and 2x4 collaborated to design and integrate an interactive media environment as part of Pole Dance. Eight of the fiberglass poles incorporate accelerometers – devices that measure the motion of the poles - and convert it to sound played back in the courtyard using MaxMSP. In the installation’s passive state, sound is generated by wind moving the poles or netting. As the audience interacts with elements of the structure – by pushing, pulling or shaking the poles or moving the beach balls or the net, modulated tones are generated. The tones have been specifically composed to blend with the sonic environment and to bring harmony to the soundscape in and around the museum. The installation is truly interactive with up to 8 participants able to simultaneously “play” the poles. In this way the installation becomes a multi-user instrument that can be shared by ensembles of visitors of all ages. Rapid and shallow movements create locally oscillating tones; movements made by leaning on the poles create a sound that ripples out into the rest of the garden as the network of connected poles are set in motion.

An interactive iPhone app allows visitors to affect the quality of sound for each pole in real time. By turning the effects levels up or down the audience can collaboratively vote to change the active sound of their environment. The application also collects the movements of the interactive poles sent out to the network by Max and visualizes the dynamic activity and movement within the installation in real time.

project101-pole-dance-interactive-multimedia-sound-installation

Pole Dance - Interactive multimedia sound installation

dodgeroo

2 simple patches that send and receive audio over a local area network.

i found lots of options for sending audio over a network but not much about sending it in both directions.  these are max patches, so they can easily be integrated inside any max patch one is working on.  Unlike JackOSX, etc.

send-and-receive-audio-over-lan

send and receive audio over LAN

Gokce Kinayoglu

Update: Version 1.2 is available to download, adding support for custom Twitter API keys. This was requested by some users to increase reliability. Version 1.0 and 1.1 do not work any more due to changes in Twitter's API.

Searchtweet is a mxj external that searches twitter with a given keyword and returns a desired maximum number of most recent posts, with username, date and twitter text body routed to separate outlets. The object returns a specified number of most recent twitter posts that contain a given keyword, #hashtag, or @usertag.

Advanced search queries also work:
https://support.twitter.com/articles/71577-using-advanced-search

Searchtweet uses the twitter4j library (http://twitter4j.org) programmed by Yusuke Yamamoto.

Note:
Unless custom API keys are entered, the plugin will default to its own authentication keyset. This may limit the number of searches per given time. Eg. You must optimize your search frequency to avoid hitting the API rate-limits. (Ex. Do not connect a [metro 10] to the inlet, your IP will be banned in no second)

For more info:
https://dev.twitter.com/docs/faq

searchtweet-design-patches-that-respond-to-twitter-posts

Searchtweet - Design patches that respond to twitter posts.

Ryan

We use Max as a show control master computer, the show is automated and Max connects with computers and a light board on a local network to issue commands. I program in Max 4.6 and communicate through MIDI, OSC and Serial to control the performance.

Search Results