LINUX.ORG.RU

Децентрализованная музыкальная студия

 


0

1

Доброго всем времени суток. У меня появилась идея создания музыкальной студии, но децентрализованной. На python ставиться сервер, снимает данные с миди клавиатуры и посылает клиенту, там уже эти данные записываются и обрабатываются. Музыкантам необязательно присутсвовать всем в одной студии, они хоть откуда могут свои партии записывать. Как идея?


А зачем студия. Почему просто каждый не может свою партию хоть по имейлу закинуть?

Deleted
()
Ответ на: комментарий от Radjah

Задержки нет, потому что текстовая информация пересылается, можно проверить если кто желает

dm64
() автор топика
Ответ на: комментарий от Deleted

<А зачем студия. Почему просто каждый не может свою партию хоть по имейлу закинуть?> Так одновременно играть они не могут))) Я на форуме FreeBSD эту тему двигал, но там всё сурово, на linux люди более отзывчивые и гибкие.

dm64
() автор топика

Лучше на PHP, на python звук хуже.

thesis ★★★★★
()
Ответ на: комментарий от dm64

Задержки нет, потому что текстовая информация пересылается

отсыпь и мне такого порошка

reprimand ★★★★★
()
Ответ на: комментарий от anonymous

Вот наглядно. Посмотрите:

Сервер

import socket import os

sock = socket.socket() sock.bind((",22)) sock.listen(0) conn, addr = sock.accept()

print ('connected:', addr)

i = 0 while True: data = conn.recv(1024) conn.send(data.upper()) os.system(«sleep 5; gnome-screenshot») i = i + 1 conn.close()

Клиент

#!/usr/bin/env python # -*- coding: utf-8 -*-

import socket import os f = open(«/dev/midi»,«r»)

sock = socket.socket() sock.connect(('100.100.62.2', 9090))

while True: s = f.read(1) sock.send(s) print s data = sock.recv(1024) sock.close() f.close() print data

Эта программа также шпионить может)))) Но я против такого рода вещей.

dm64
() автор топика
Ответ на: комментарий от dm64

Вот часть которая читает данные с клавиатуры: #!/usr/local/bin/python import usb.core import usb.util import usb.backend import jackpatch

dev = usb.core.find(idVendor=0x0763, idProduct=0x019b) dev.set_configuration() endpoint = dev[0][(0,0)][0]

client = jackpatch.Client(«superduper») midi_out = jackpatch.Port(client, «midi_out», flags=jackpatch.JackPortIsOutput)

while True: data = dev.read(endpoint.bEndpointAddress,endpoint.wMaxPacketSize, 1, 0) print data midi_out.send(data)

dm64
() автор топика
Ответ на: комментарий от anonymous

<ты из 9-ого Б?> Нет, я уже взрослый. Но учился да в Б ))))

dm64
() автор топика

но децентрализованной
На python ставиться сервер
ставиться сервер,
сервер,
но децентрализованной

anonymous
()
Ответ на: комментарий от dm64

Вот ping элитного компьютера с элитным интернетом:

user@work:~$ ping -c 5 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=42 time=54.1 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=42 time=51.2 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=42 time=49.9 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=42 time=48.7 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=42 time=47.8 ms

--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 47.819/50.370/54.101/2.205 ms
user@work:~$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1)  0.775 ms  0.886 ms  0.893 ms
 2  * * *
 3  10.78.254.153 (10.78.254.153)  28.798 ms  29.483 ms  29.793 ms
 4  10.78.248.34 (10.78.248.34)  37.639 ms  50.819 ms  51.604 ms
 5  * * *
 6  10.78.247.33 (10.78.247.33)  63.210 ms  61.239 ms  63.775 ms
 7  10.78.248.41 (10.78.248.41)  54.879 ms  37.393 ms  35.286 ms
 8  10.78.250.162 (10.78.250.162)  39.331 ms  31.073 ms  34.272 ms
 9  ip-83-149-1-145.nwgsm.ru (83.149.1.145)  38.088 ms  32.774 ms  39.346 ms
10  ip-83-149-6-242.nwgsm.ru (83.149.6.242)  45.698 ms  45.422 ms  46.463 ms
11  37.29.105.34 (37.29.105.34)  51.167 ms  49.393 ms  49.498 ms
12  37.29.17.87 (37.29.17.87)  47.788 ms  43.773 ms  43.538 ms
13  216.239.42.95 (216.239.42.95)  49.378 ms 216.239.42.97 (216.239.42.97)  42.381 ms  41.866 ms
14  216.239.42.53 (216.239.42.53)  54.611 ms 216.239.42.85 (216.239.42.85)  49.394 ms  47.657 ms
15  209.85.249.79 (209.85.249.79)  48.611 ms  39.059 ms  37.061 ms
16  216.239.56.208 (216.239.56.208)  41.735 ms  50.737 ms  51.322 ms
17  * * *
18  google-public-dns-a.google.com (8.8.8.8)  51.688 ms  51.293 ms  47.042 ms
user@work:~$ 

При этом надо понимать, что это DNS гугла, компы с обычным подключением могут давать и большие задержки.

torvn77 ★★★★★
()

Музыкантам необязательно присутсвовать всем в одной студии

Ох уж эти линуксоиды, им лишь бы с людьми не общаться.

cipher ★★★★★
()

Таких упоротых я еще не встречал!)

dk-
()
Ответ на: комментарий от torvn77

ping -c 5 8.8.8.8

Это небольшие задержки. Когда я только купил мидюху и подключил на windows, то там(и сейчас) были такие задержки что играть было не возможно. Давайте попробуем, если у кого белый айпи, или кто знает может можно коннектиться как кто без белого айпи?

dm64
() автор топика
Ответ на: комментарий от quantum-troll

Давайте мерить свои пингюны

$ ping -c 5 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=44 time=6.80 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=44 time=6.07 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=44 time=6.64 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=44 time=7.25 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=44 time=6.73 ms

anonymous
()
Ответ на: ping -c 5 8.8.8.8 от dm64

Джек умеет работать через сеть, если так хочется,почему бы не проверить сначала то, что есть?

И учти, что задержки будут в два раза больше, чем просто пинговать. Получил сигнал, услышал звук, нажал клавишу,сигнал пошёл назад, двойная задержка!

Deleted
()
Ответ на: комментарий от quantum-troll

в некоторых игрульках через udp было 5 мс, но это с отдельной линией и дорогим роутером

reprimand ★★★★★
()
Ответ на: комментарий от Deleted

Джек умеет работать через сеть

ты тестил его? мне самому интересно, а то с пшшшшаудио возиться нет желания

reprimand ★★★★★
()
Ответ на: комментарий от torvn77

Уже помогли выше:
1. 6-15 мс — весьма малые задержки, скорее всего можно играть даже без синхронизации.
2. Синхронизация важнее задержек. Программы вроде Ninjam и Jamulus могут даже увеличивать задержку, но благодаря грамотной синхронизации они позволяют без проблем играть вместе.

quantum-troll ★★★★★
()
Последнее исправление: quantum-troll (всего исправлений: 1)
Ответ на: комментарий от Deleted

Джек умеет работать через сеть, если так хочется,почему бы не проверить сначала то, что есть?

Давайте jack проверим, только за

dm64
() автор топика
Ответ на: комментарий от reprimand

Я сыну по вайфаю планшет подключал, на планшете дрампад, на компе lmms. Задержка локального джека- минимальная, но через сеть плохо, но привыкнуть можно, потому что связь, фактически односторонняя, с планшета на комп.

То, что предлагает ТС - оба музыканта слышать только локальный звук, тоесть, полная задержка сети и джека в обе стороны.

Deleted
()
Ответ на: комментарий от anonymous

Но зачем, если есть скайп

Skype midi не читает.

dm64
() автор топика
Ответ на: комментарий от reprimand

Я только миди передавал. А реалтайм звук по сети, туда и обратно? Сильно сомневаюсь в том, что будет толк, что это вообще имеет смысл. А если тебе просто музычку, то удобнее пульса я на линуксе не знаю.

Deleted
()

видишь, у тебя, кроме идеи игры по сети, ничего нет. Так технарей можно найти, кому кодить интересно. А музыкантам, нужна - во первых, идея, а во вторых, компания. Вот никто и не клюёт.

Deleted
()
Ответ на: комментарий от Deleted

не, мне просто риалтайм музычку передавать с одного хоста на другой

пульсой пользовался, спасибо, покушал, хватило. К слову о ноутах, на моём ноуте пульса просто отвратительно работает. Не зря её ругают как говняный софт.

reprimand ★★★★★
()
Ответ на: комментарий от dm64

Задержки нет, потому что текстовая информация пересылается, можно проверить если кто желает

Подсказка - скорость света конечна. Даже при идеальном оборудовании

upcFrost ★★★★★
()

Звучит как будто ты неосилятор jack по сети, а jack это промышленный стандарт. Или, если хочется странного, то usbip для проброски устройства. Вместо этого ты же предлагаешь нестандартное и узкое решение. И что-то мне сдаётся что ты хочешь чтобы тебе его написали. А так сам-то пиши, чо. Покажешь потом свой «сервер на python».

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

для slovazap

Я так то написал, только проверить, я проверял только локально. Ну и к тому же я уже писал что музыканты до сих пор все новые сетевые технологии не используют. Все топовые программы для записи музыки работают только в локальном режиме(насколько я знаю).

dm64
() автор топика
Ответ на: комментарий от torvn77

Сообщение в теме двухдневной давности - уже некропост? Упоролся?

Chaser_Andrey ★★★★★
()
Ответ на: комментарий от Radjah

да всё решаемо. есть весьма успешные реализации. я сама много играла в таких онлайн джемах. звук качества не для студийной записи, но для прослушиания и совместной игры хватает вполне. для канала в 48kHz не нужно много трафика. за треки можно писать на местах, а потом сводить. задержки даже при довольно тощих сетях не слышимые ухом. проблемы составляют WiFi сети (у них структура такая, что стриминг хреново работает).

Iron_Bug ★★★★★
()
Ответ на: комментарий от dm64

зайти на jamkazam.com, например. всё используют. но вот про Линюкс у них нет клиента. а хотелось бы. я им писала, они вроде как планировали что-то под Линюкс, но потом это заглохло. если бы протокол знать, можно было бы написать клиента. думаю, он там не такой сложный.

Iron_Bug ★★★★★
()
Ответ на: для Iron_Bug от dm64

реверсинженеринг протокола и собственная реализация клиента под линукс ждет тебя

anonymous
()
Ответ на: комментарий от anonymous

вполне вероятно. если у меня появится достаточно свободного времени, я могу этим заняться. я уже думала над этим. я им предлагала сотрудничество в плане разработки клиента под Линюкс, но они как-то вяло отмазывались. скорее всего, это связано с коммерциализацией проекта и они не хотят открытых протоколов.

Iron_Bug ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.