In a previous post there was mention of scenes. I would like to have the ability to be able to save and load Scenes for a network node. The scene data would include the virtual names and the routings. I have multiple nodes that have close to 32 virtual names each. These PCs have a Midisport16 attached. On the PCs that run the Sequencer and especially on the Patch Editor, I end up with well over 80 ports that Windows is going to create a port for. This adds a significant amount of overhead to the PC as well as a nightmare of routings. Since there are 5 nodes with the Midisports, if I could save and load the connections and virtual names, it would cut down on the number of active windows ports and simplify the complexity of the connections.
That’s an excellent idea! we’ve already had an idea to be able to use different MIDI route sets, but ‘scenes’ is a better term, and as you suggest, they could include
- MIDI routings
- virtual ports
- network connections
- Remote Direct MIDI
As I understand, you wouldn’t want to have ‘global’ scenes, where the entire state of the above is restored, but rather ‘per network connection’. Is that right? If yes, I wonder how that could be set up… Any ideas?
I have been working with the setup for computer to computer connections in Bome Networking and I have either missed something or there is a hole that needs to be addressed and scenes could be the answer. Let me describe the simple case that is causing a problem. I have two keyboards that are connected via an M-audio 4x4 to a laptop running Bome network. The keyboards are defined with virtual midi names and are routed to the interface. Across the network I have a rack of synths connected to a MidiPlus 16x16 midi interface connected to a mini PC named Rack1A. This PC is also running Bome. All synths have virtual midi names and are mapped to the ports on the Midiplus. When I connect the laptop to Rack1A , Bome on the laptop create a pair of in and out virtual ports to Rack1A. However, I need to be able to route a given keyboard(M8000) attached to the laptop to a specific synth(Motif ES) in Rack1A. When I go into Bome on the laptop, none of the synth virtual names from Rack1A show up in the Virtual Ports and therefore I cannot create a routing from the M8000 or Midi4x4 out 1 to the MotifES Virtual In or the Midiplus 16x16 out 3. I am running everything using V1.6 and I think this actually worked in V1.4.
- Did I miss something in my configuration?
- Is this a bug in V1.6
- Is my memory wrong about working in 1.4?
- What I am currently seeing does not make sense from the perspective of running a single 32kbs midi port across a 1GB network. With the Gigabit bandwidth. we should be able to run dozens of midi connections across the network.
When I go Rack1A machine, there is only a single virtual port for the laptop showing. and likewise on the Laptop there is only a single virtual port for Rack1A.
What I think should happen is that when I connect to Rack1A from the laptop, all of the Virtual Ports on Rack1A should be visible on the laptop to be able to route to. I should then be able to select which virtual ports I will use (i.e. delete them from the Virtual ports list) Then go ahead and do the route configuration. This would constitute a ‘Scene’ that could be saved and restored. With 2 keyboards attached to the laptop and several synths in Rack1A, one can create numerous ‘Scenes’ that represent different combinations of keyboards and synths that could be saved and loaded. These could be flat files that are stored in the same location as the current settings file.
While it would be wonderful to store a truly comprehensive map of the setting across the whole network, I don’t think it is practical. When you get to complex setups with about 12 midi source devices, 4 rack PCs(about 40+ synths currently), 2 source PCs(keyboards,edrums and others) and a Patch Librarian/Editor PC, a Sequencer PC and a VST PC, the combinations are a ridiculous number and keeping track of naming would be insane. Reducing that down to 4 controlling PCs (eliminate the rack PCs and the VST since their connections are static) and this become manageable as you would only be creating scenes on 4 machines and of those, the Patcher would have a limited number of Scenes (1 for each rack).
In the post I have read on the forum, it appears that many users of Bome Networking are also using it in a Master/Slave environment , so having the save and load on a functional Master rather than a complete global network would meet the needs.
In summary:
- From a ‘Master’ node be able to connect to multiple other nodes and see all connections on each node(ideally being able to select the virtual names before the Windows device creation process, so you do not have to delete them afterwards.
- Create routings that span the network (creating routes from the ‘Master’ node to the various virtual devices across all other nodes)
- Be able to save and load each of these sets of configurations(virutal name connections and routings) as a file.(When a file is loaded all Windows devices are deleted and new Windows devices are created based on the file loaded.)
Comments appreciated!
James
To clarify the prior post, a ‘Master’ is just a node that is used to configure/implement dynamic network connections to virtual names across multiple nodes. In the prior discussion the midi source PCs, the Sequencer Pc and the Patcher PC would all be considered ‘Masters’ as they need to be able to do multiple dynamic routings (Save and Load). The rack PCs and VST PC are Slaves because all they do is acts as servers making their synths available to the network and the only routing is to map Virtual names to the physical ports on the interface.
This does not imply however, that a node cannot be both a ‘Master’ and a ‘Slave’ at the same time. For example, if you ran a VST host outside a DAW then the VST host side would be a Slave serving its VST synths but your midi inputs to the DAW could be dynamic so you have both elements.
Hi @jmcdouga , thanks for the additional thoughts. I understand that from your point of view, it makes sense to separate into ‘Master’ and ‘Client’ (we try to use ‘modern’ terminology). But the software should probably be agnostic towards this concept.
This will be a big step, and still a few other things on our plate…
Thanks!
I have changed my terminology to use the terms Requester and Provider. A node could be a Requester (requests a connection), a Provider (makes connections available) or a combination of both functions. To illustrate and to provide context for my comments about scenes later in this post, let me provide an example. I have several nodes that have synths attached. These nodes are Providers as they make the midi connections to these synths available to the network. I also have nodes that have either software(patch editor, sequencer) or input devices (keyboards, edrums) attached to them. These are Requester nodes as they request connections to the nodes/synths to play them.
(Please note that my environment is near the extreme end of complexity for a PC based midi lan network. However, anything that works in my environment should work for anybody.)
When a connection is made by a requester and the individual connections to the units on the provider node are enabled, a series of software devices are created on the requester PC that represent these ports. Likewise when the connection is disconnected, these software devices are removed. This is a good thing as these represent overhead on the PC.
In playing with the patch editor and needing to connect to multiple units on a node and having several nodes, it is a real nuisance to go through and enable multiple connections every time I need to do some editing or load a different set of patches. If I could create the connections for each node and then store that configuration for that node as a scene, then I could simply load a scene and the connections as well as the enablement of the attached devices/routing would all be a single step.
This is even more of an issue with a sequencer when one would have tracks /connections that span multiple nodes so a project in the sequencer would have a corresponding scene in Bome. To execute, you load a scene Bome and then open the sequencer software and project. This sequence is required as so far, I have found that the software I am using, MidiQuest and Sonar load the available midi ports at software startup and they do not appear to have the capability to refresh once the software is loaded. I suspect this is typical of most software.
The concept of Scenes would also work very well in a Live Performance environment. With a pair of keyboards connected via wireless midi or a usb midi device located with the keyboards and connected back to a laptop via USB over cat6, one could have multiple VSTs on the laptop and have scenes that route the keyboards to different VSTs and/or a NUC providing a few high function racked synths(with plugin cards for Yamaha and Roland JV rack synths, these unit can literally have hundreds of patches).
There are many more situations where the ability to create, store and load scenes would be very valuable.
Please add your comments as to how you could use the concept of scenes in your environment.
Interesting concept.
Here is the way I currently handle this since no ‘Scenes’ currently exist.
There is a file located Windows PC in %AppData%\Bome called BomeNet.bmts. This is a setting file for the current running BomeNet. Once I get it to how I want I make a copy and name it something else of your Choosing. Say I call the file ‘Scene1.bmts’
- Close Bome Network
- Rename BomeNet.bmts to something else
- Copy Scene1.bmts to BomeNet.bmts
- Restart Bome Network. It will then start up and read and configure using the file you selected.
I could use a scripting language like ‘AutoHotKey’ to do this for me but I don’t switch configurations very often
This would need to be done on each node you want when changing a Scene on that Node.
I envision that perhaps at some point in the future, maybe Bome Network, would have a ‘scene manager’ that could select the settings file that you want to use. Maybe without shutting down Bome Network, but not sure if that is possible.
So a button that you can click to save your current Scene settings to a name you want. Then another button to load and activate the Scene that you want.
Does that sound like something that would work for you.
Note, that Florian also posted another possible method here.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
Hi,
This will not be supported by me but I created an AutoHotKey script to create and or select existing scenes based on the saved or running BomeNet .bmts file.
You need AutoHotKey 1 to use it. AutoHotKey runs only on Windows.
/*
Title: Bomenet Scene Switch
Description: Create new or select old scene for use.
AutoHotKey_L Version: 1.1.09.00
Written by: Steven J. Caldwell
Last Update: 2024-01-17
Other Notes:
For selecting a new Scene:
Original running .bmts file is saved in Temp with a date and time stamp when selecting a new scene. It will overwrite if already
created.
Bome Network will be stopped and restarted.
For creating a new Scene from the running file:
If no file extension is input when creating a new scene it will be added. If the filename entered exists it will not be created.
*/
; Command Line Options go here Modify as necessary
/* Uncomment this section if you will be using arguments
if 0 < x ; Change x to the number of required arguments
{
MsgBox 0,Usage,Usage is:`n
}
else
{
; Do something here
}
*/
;Start Code below this line
FileDir:= "%AppData%" . "\Bome\"
TempDir:= "%TEMP%" . "\"
EnvGet,DestDir,TEMP
EnvGet,SourceDir,AppData
; MsgBox %FileDir%
;ExitApp
Gui, New, , Change BomeNetwork Scenes
Gui, Font,s20
Gui, Add, Text, x10 , Select a preset scene file
Gui, Add, Button,gSelect x+10 , Select
Gui, Add, Text,y+10 x10, Save a preset scene file
Gui, Add, Edit,vNewFile w300 x10 y+10, BomeNetScene
Gui, Add, Button,gSave,Save
Gui, Add, Button,gCancel,Cancel
Gui, Show
Return
ExitApp
GuiClose:
ExitApp
Cancel:
ExitApp
Save:
Gui Submit
Gui Hide
Found := Instr(NewFile,".bmts")
if (!Found)
{
NewFile:= NewFile . ".bmts"
}
; MsgBox, New file is %NewFile%
Source:= SourceDir . "\Bome\BomeNet.bmts"
Dest:= SourceDir . "\Bome\" . NewFile
; MsgBox %Source% `n%Dest%
FileCopy, %Source%, %Dest%
if ErrorLevel
{
Msgbox Could not create new scene - %NewFile%`nMaybe it exists
}
ExitApp
Select:
Gui Hide
FileSelectFile,NewConfig,,%FileDir%,Enter the file that you want,BomeNet*.bmts
; MsgBox, %NewConfig% Selected
DetectHiddenWindows, On
;if (WinExist,"ahk_exe BomeNet.exe")
RunWait , %A_AhkPath% "ProcessCheck.ahk" "BomeNet.exe" ,%A_WorkingDir%,Hide UseErrorLevel
if ErrorLevel ; i.e. it's not blank or zero.
{
Msgbox, ,Bome Scene, Bome Network Not running, 2
;ExitApp
}
else
{
; Msgbox,,, Killing Bome Network,2
Process, Close, BomeNet.exe
Process, WaitClose, BomeNet.exe,5
if ErrorLevel
{
Msgbox,,, Could not kill Bome Network, 2
ExitApp
}
}
; Save old file
FormatTime, ShortDate,A_Now,yyyy-MMM-d-HH-mm
Dest:= DestDir . "\BomeNet-" . ShortDate . ".bmts"
Source:= SourceDir . "\Bome\BomeNet.bmts"
;Msgbox, Source=`"%Source%`" Dest=`"%Dest%`"
;ExitApp
FileCopy, %Source%, %Dest%, 1
if ErrorLevel
{
Msgbox,, Error, Could not copy old file,5
}
; Copy New File
Dest:= SourceDir . "\Bome\BomeNet.bmts"
Source:= NewConfig
; Msgbox, Source=`"%Source%`" Dest=`"%Dest%`"
; ExitApp
FileCopy, %Source%, %Dest%, 1
if ErrorLevel
{
Msgbox,, Error, Could not copy new file,5
}
;; Startup Bome Network
Run, "C:\Program Files (x86)\Bome Network\BomeNet.exe",,,PID
if (ErrorLevel = "ERROR")
{
MsgBox, Could not Start Bome Network
}
else
{
;MsgBox,,, Bome Network Restarted PID = %PID%, 5
}
ExitApp
!q:: ExitApp
;End Standard Code here
;Includes here
And here is the file attachment. You will need to rename the extension to from .txt to .ahk
Bomenet-Scene.txt (3.2 KB)
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz