Автор Тема: REACT:IR - реактивная нагрузка + аттенюатор + загрузчик импульсов  (Прочитано 238228 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн Дмитрий Чаусов

  • Частый посетитель
  • **
  • Сообщений: 123
  • Репутация: +12/-0
  • GuitarPlayer.Ru fan!
А я хочу продать свой ReactIR. Есть желающие купить?

Оффлайн Poosh

  • Опытный
  • ****
  • Сообщений: 566
  • Репутация: +147/-7
  • In Flames We Trust
А я хочу продать свой ReactIR. Есть желающие купить?

а тут что, тема с продажами?

Оффлайн einzig

  • Ветеран форума
  • ******
  • Сообщений: 3064
  • Репутация: +982/-52

Оффлайн vasilius Автор темы

  • Эксперт
  • *****
  • Сообщений: 2177
  • Репутация: +524/-1
  • www.st-rock.com
    • st.Rock
Давно хотел попробовать, но руки не доходили....

Для тех, кто использует реактир как аттенюатор, есть еще интересный способ...
Можно взять сигнал с выхода на наушники, соединить  два "горячих" провода вместе и подать на кабинет....
Можно использовать пустой слот без импульса, а можно и с импульсами - прикольно получается....

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

Оффлайн Lowbobybob

  • Опытный
  • ****
  • Сообщений: 975
  • Репутация: +132/-7
Планируется ли обновление софта для macOS? Порт на M1, да и под интеловские 64 бита?

Оффлайн vasilius Автор темы

  • Эксперт
  • *****
  • Сообщений: 2177
  • Репутация: +524/-1
  • www.st-rock.com
    • st.Rock
Планируется ли обновление софта для macOS? Порт на M1, да и под интеловские 64 бита?

На текущий момент поддерживается последний  Big Sur 64 bit. Новее, вроде, не вышло еще ничего ( я не маковод).

АRМ:
Мы привязаны к обновлениям языка программирования, на котором написан софт.
И специально переписали софт в третий раз, чтобы не было проволочек с обновлением МасОС
Обновлением для ARM под МакОС запланировано на вторую половину этого года.
Как только среда разработки даст возможность скомпилировать под эту платформу - мы сразу же выпустим обновление.


Оффлайн BRMC

  • Эксперт
  • *****
  • Сообщений: 1139
  • Репутация: +195/-0
  • Whatever happened to my Rock'n'Roll
От FX отказались окончательно?

Я думал, что только в версии под Мак нет.
А неделю назад под Виндой подключил, и там эффектов нет.

Но плашка FX в интерфейсе осталась

Оффлайн vasilius Автор темы

  • Эксперт
  • *****
  • Сообщений: 2177
  • Репутация: +524/-1
  • www.st-rock.com
    • st.Rock
От FX отказались окончательно?

Я думал, что только в версии под Мак нет.
А неделю назад под Виндой подключил, и там эффектов нет.

Но плашка FX в интерфейсе осталась

Да

Оффлайн Lowbobybob

  • Опытный
  • ****
  • Сообщений: 975
  • Репутация: +132/-7
На текущий момент поддерживается последний  Big Sur 64 bit. Новее, вроде, не вышло еще ничего ( я не маковод).

АRМ:
Мы привязаны к обновлениям языка программирования, на котором написан софт.
И специально переписали софт в третий раз, чтобы не было проволочек с обновлением МасОС
Обновлением для ARM под МакОС запланировано на вторую половину этого года.
Как только среда разработки даст возможность скомпилировать под эту платформу - мы сразу же выпустим обновление.
Не совсем понял. У вас приложение под мак на Свифте/Obj-C или на плюсах? Или кор на плюсах, а остальное на Свифте/Obj-C? В любом случае Свифт уже давно не «ломается» обновлениями. Obj-C и плюсы так и подавно. Все ведь зависит от билд-системы, а не от языка.
Xcode уже полгода как позволяет собирать проект под М1. На выходе просто универсальный бинарь. Вернее, если более точным быть, ОС в рантайме выбирает нужную версию из двух (x86_64 или arm64). Это если вы к Xcode привязаны. Если вы собираете чем-то другим, то в любом случае, llvm ведь миллион лет как уже знает про ARM  ???

Вы меня простите за навязчивость в вопросах. Я просто хочу быть уверен, что купив ваш прибор, смогу после покупки нового мака спокойно продолжать его (react:ir) использовать.
« Последнее редактирование: Марта 08, 2021, 21:49:58 от Lowbobybob »

Оффлайн vasilius Автор темы

  • Эксперт
  • *****
  • Сообщений: 2177
  • Репутация: +524/-1
  • www.st-rock.com
    • st.Rock
Не совсем понял. У вас приложение под мак на Свифте/Obj-C или на плюсах? Или кор на плюсах, а остальное на Свифте/Obj-C? В любом случае Свифт уже давно не «ломается» обновлениями. Obj-C и плюсы так и подавно. Все ведь зависит от билд-системы, а не от языка.
Xcode уже полгода как позволяет собирать проект под М1. Это если вы к нему привязаны. Если вы собираете чем-то другим, то в любом случае, llvm ведь миллион лет как уже знает про ARM  ???

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

Изначально - я совершил большую ошибку, выбрав, в качестве среды разработки - С++ Builder. Как среду, позволяющую собирать проект под разные ОС с одним кодом, и с одним! GUI.
В момент выбора - это был логичный и оправданный выбор - так как, ничего не предвещало беды и работало как и задумывалось.
Сначала софт для reacr:IR выглядел проще, умел только загружать импульсы и все.
Вторая версия софта - это то как софт выглядит сейчас - микшер импульсов, матчер и т.п. И вроде все было хорошо.
Но потом Apple жестко всех перевел все на 64бит. А ребята с Embarcadero внезапно решили, что сапортить С++ Builder под мак ос 64 бит им не интересно. И самое печальное, не могли год в этом признаться. Хотя поддержку их основного продукта - Delphi они ведут исправно под все ОС.
И ситуация до сих пор плачевная в этом направлении.

Чтобы обеспечить нашим пользователям возможность работы в МакОС у  нас было два варианта - перейти на Juce или переписать весь проект на Delphi.
На Juce мы не могли перейти - потому, что не смогли бы воспроизвести тот GUI который уже есть и к которому все юзеры уже привыкли.
Оставался один вариант - переход на Delphi. Нам пришлось портануть весь проект с С++. На это ушло несколько месяцев. И было больно.
Так появилась 3-яя версия софта - текущая.

Если Вы думаете, что после такой истории, после того, сколько было сделано, мы сможем просто бросить продукт... Вы ошибаетесь... -)


Оффлайн deLuther

  • Живу на форуме
  • *******
  • Сообщений: 34216
  • Репутация: +3361/-40
  • alderman of morning star
    • Malefice
Точнее часть проекта отвечающую за GUI, а DSP-часть просто на С++ перенести окончательно, чтобы можно было библиотеку сделать в Xcode.
Даже побочный бонус вышел - стало быстрее немного :)
DSP-часть сделать многоплатформенной проще, чем GUI.

Оффлайн Lowbobybob

  • Опытный
  • ****
  • Сообщений: 975
  • Репутация: +132/-7
Изначально - я совершил большую ошибку, выбрав, в качестве среды разработки - С++ Builder. Как среду, позволяющую собирать проект под разные ОС с одним кодом, и с одним! GUI.
В момент выбора - это был логичный и оправданный выбор - так как, ничего не предвещало беды и работало как и задумывалось.
Сначала софт для reacr:IR выглядел проще, умел только загружать импульсы и все.
Вторая версия софта - это то как софт выглядит сейчас - микшер импульсов, матчер и т.п. И вроде все было хорошо.
Но потом Apple жестко всех перевел все на 64бит. А ребята с Embarcadero внезапно решили, что сапортить С++ Builder под мак ос 64 бит им не интересно. И самое печальное, не могли год в этом признаться. Хотя поддержку их основного продукта - Delphi они ведут исправно под все ОС.
И ситуация до сих пор плачевная в этом направлении.

Чтобы обеспечить нашим пользователям возможность работы в МакОС у  нас было два варианта - перейти на Juce или переписать весь проект на Delphi.
На Juce мы не могли перейти - потому, что не смогли бы воспроизвести тот GUI который уже есть и к которому все юзеры уже привыкли.
Оставался один вариант - переход на Delphi. Нам пришлось портануть весь проект с С++. На это ушло несколько месяцев. И было больно.
Так появилась 3-яя версия софта - текущая.

Если Вы думаете, что после такой истории, после того, сколько было сделано, мы сможем просто бросить продукт... Вы ошибаетесь... -)


Обалдеть подход конечно. Аплодирую вам обоим за упорство.
А не думали уйти от подхода с полностью единой кодовой базой, которая должна быть кроссплатформенной, в сторону shared части + все-таки платформенного UI?
- DSP модуль как статичная библиотека. На уровне core.
- Бизнесовая логика, юзающая кор, на тех же плюсах либо Kotlin Multiplatform. Подключается в macOS-проект просто в виде статической библиотеки. Все тем же Xcode.
- UI на разных платформах как удобно. Для macOS это AppKit.

Да, делать правки в UI для одной платформы отдельно - немного дольше. Но это избавило бы вас от зависимости от сторонней билд-системы, в случае выбора  C++ для бизнеслогики. А в случае выбора Kotlin MPP доверия JetBrains всяко больше.  Это по сути набор компиляторов и инструментов работы с их языком, который довольно популярен уже и имеет прекрасное ясное будущее ))

... и добавил:

Наверное, я вам предложил путь, о котором вы сами уже много раз подумали  :pozor:
Понимаю, что переписывать приложение ещё раз вам не очень хочется.
« Последнее редактирование: Марта 08, 2021, 23:56:48 от Lowbobybob »

Оффлайн vasilius Автор темы

  • Эксперт
  • *****
  • Сообщений: 2177
  • Репутация: +524/-1
  • www.st-rock.com
    • st.Rock
Обалдеть подход конечно. Аплодирую вам обоим за упорство.
А не думали уйти от подхода с полностью единой кодовой базой, которая должна быть кроссплатформенной, в сторону shared части + все-таки платформенного UI?
- DSP модуль как статичная библиотека. На уровне core.
- Бизнесовая логика, юзающая кор, на тех же плюсах либо Kotlin Multiplatform. Подключается в macOS-проект просто в виде статической библиотеки. Все тем Xcode.
- UI на разных платформах как удобно. Для macOS это AppKit.

Да, делать правки в UI для одной платформы отдалено - немного дольше. Но это избавило бы вас от зависимости от сторонней билд-системы, в случае выбора  C++ для бизнеслогики. А в случае выбора Kotlin MPP доверия JetBrains всяко больше.  Это по сути набор компиляторов и инструментов работы с их языком, который довольно популярен уже и имеет прекрасное ясное будущее ))

Мы рассуждаете как маковод.... -)
А мы должны думать о всех ОС. 

Важным было иметь общий гуй, чтобы саппорт юзеров был вне зависимости от ОС. Естественно, не имея садомазо наклонностей, хотелось иметь еще и единый общий код.
Иначе пришлось бы вести отдельную ветку софта для каждой ОС. А это как раз то, чего и хотелось избежать...

По сути сейчас есть core - написаный на С++, который собирается в библу на VC++ под винду, и  собираемая на XCode под мак.
Тоесть самое сложное собирается нативно под каждую ОС. Лучше, и стабильней, чем VC++ и XCode, нет ничего.
И есть ГУЙ написаный на делфе, который обеспечивает одинаковую картинку для всех юзверей.
На этом и остановились....

Полагаю, что все точки над i мы расставили, и нет более смысла отвлекать участников топика, специфичными программерскими нюансами...
Если у Вас остались, какие-то вопросы на эту тему - велкам в личку... Но, думаю, Вам понятен наш подход, и наше понимание происходящего.  -)

« Последнее редактирование: Марта 09, 2021, 00:11:52 от vasilius »

Оффлайн Lowbobybob

  • Опытный
  • ****
  • Сообщений: 975
  • Репутация: +132/-7
Мы рассуждаете как маковод.... -)
А мы должны думать о всех ОС. 

Важным было иметь общий гуй, чтобы саппорт юзеров был вне зависимости от ОС. Естественно, не имея садомазо наклонностей, хотелось иметь еще и единый общий код.
Иначе пришлось бы вести отдельную ветку софта для каждой ОС. А это как раз то, чего и хотелось избежать...

По сути сейчас есть core - написаный на С++, который собирается в библу на VC++ под винду, и  собираемая на XCode под мак.
Тоесть самое сложное собирается нативно под каждую ОС. Лучше, и стабильней, чем VC++ и XCode, нет ничего.
И есть ГУЙ написаный на делфе, который обеспечивает одинаковую картинку для всех юзверей.
На этом и остановились....

Полагаю, что все точки над i мы расставили, и нет более смысла отвлекать участников топика, специфичными программерскими нюансами...
Если у Вас остались, какие-то вопросы на эту тему - велкам в личку... Но, думаю, Вам понятен наш подход, и наше понимание происходящего.  -)
Да, мне все понятно, спасибо за подробные ответы  :rolleyes:

Оффлайн kardashin

  • Живу на форуме
  • *******
  • Сообщений: 7676
  • Репутация: +12010/-13
Лучше, и стабильней, чем VC++ и XCode, нет ничего.
Qt