TommyC81
Repos
11
Followers
7

Events

Update README.md

Created at 1 week ago

Screenshots

Created at 1 week ago

Update README.md

Spelling.

Created at 1 week ago

First upload.

Created at 1 week ago
create branch
TommyC81 create branch main
Created at 1 week ago
create repository
TommyC81 create repository
Created at 1 week ago

Fixes for DEAD event and extra nil checks

Another nil check...

further event related stuff not working any more

Update Range.lua

RANGE

  • Fixed a couple of bugs
  • Added new FSM events for strafing
  • Updated docs

SRS - adding volume setting and a test on OS and IO available

docu update

AI/ZONE - Some fixes for units unreachable

AI_AIR - restrict AB on RTB

AI_CAP - more fallout from the dead units in the API

UNIT Register - small fix for trains

AI Patrol - life check on route

Fallout fixes

GROUP - change to GetUnits(n) to make it more robust, now returns first alive unit,actually. Similar changes to GetHeading()

Group - small change

Update AI_Air.lua (#1729)

  • Update AI_Air.lua

Altered RTB airspeed (slower) and target altitude over the airfield being returned to (higher) to produce more realistic and fuel efficient descent profiles. Leads to aircraft arriving overhead the airfield quite high and generally flying one orbit to descend to land.

Scaley

  • Create AI_Air.lua

Co-authored-by: Applevangelist 72444570+Applevangelist@users.noreply.github.com

Correct link to demo missions

AIRBASE - corrected ["Deir_ez_Zor"] = "Deir ez-Zor" (minus doesn't work in enum)

SRS - actually pass the volume to the command line

SRS - put volume in "" - just in case

Point - added option to add an SSML tag to ToStringBRAANATO

Created at 2 weeks ago
opened issue
OSC: On/Off type remote device control button, no valueStr response sent for "/device/param/{1-8}/reset" messages

Software: Bitwig 4.3.4 DrivenByMoss-17.5.0-Bitwig Windows 10

When sending a "/device/param/{1-8}/reset" message for an On/Off type "button" in the remote device control, no valueStr is returned.

Log screenshot (Note: Missing valueStr in response to the reset, this is an On/Off type button): image

For all other types of remote control items (rotaries and dropdown) a valueStr message is always returned. Like so: image

Created at 2 weeks ago
opened issue
OSC: No send/receieve message for "/device/sibling/{1-8}/bypass"

Software: Bitwig 4.3.4 DrivenByMoss-17.5.0-Bitwig Windows 10

There doesn't seem to be any OSC message available for getting/setting "bypass" status for "/device/sibling/{1-8}", it is only available for the currently active device, like so: "/device/bypass".

Consider adding "/device/sibling/{1-8}/bypass" send/receive messages.

Created at 2 weeks ago
opened issue
OSC: Non-documented messages "/device/page/{1-8}/selected" and "/device/page/{1-8}/select"

Software: Bitwig 4.3.4 DrivenByMoss-17.5.0-Bitwig Windows 10

Receive - Cursor Device / Primary Device / EQ There is no documentation for the following messages that both work and seem to work the same way:

"/device/page/{1-8}/selected" and "/device/page/{1-8}/select"

They both select the (numbered) device remote control page.

The only related documented message is this: image

Created at 2 weeks ago
opened issue
OSC: Inconsistency, missing "name" tag for device remote control pages

Software: Bitwig 4.3.4 DrivenByMoss-17.5.0-Bitwig Windows 10

OSC messages related to the name for device remote control pages are missing the "name" tag. The messages simply end with a "/" rather than the expected "/name". For the device/page/selected, the message does however end with "/name".

See log below: image

This seems to be aligned with the manual, but is an inconsistent application compared to all other instances where a name is sent. Suggest to align the message to include the "/name" tag.

From the manual: image

Created at 2 weeks ago
opened issue
OSC:

Software: Bitwig 4.3.4 DrivenByMoss-17.5.0-Bitwig Windows 10

It seems the function of the following messages are reversed (or the manual is wrong or not clear): image

Using "/device/param/{+,-}" jumps 8 pages. image

Using "/device/param/bank/page/{+,-}" goes to the next/previous page: image

Created at 2 weeks ago
issue comment
OSC - When scrolling using bank/+ and bank/-, incorrect selected track indication when out of range

Fantastic!! :-)

Created at 3 weeks ago
issue comment
OSC - When scrolling using bank/+ and bank/-, incorrect selected track indication when out of range

Thank you, much appreciated, hopefully it can resolved.

I'm hoping to contribute with a well-developed tablet sized TouchOSC template in return. You've done some amazing work!

Created at 4 weeks ago
issue comment
OSC - When scrolling using bank/+ and bank/-, incorrect selected track indication when out of range

I've uploaded a video here: https://www.youtube.com/watch?v=vz39QwM1Acs

Whilst preparing the video, I discovered another bug: When the selected track has gone outside the "track window" and you then select next track, it selects next track relative to the window (still assuming that the first track in the track window is selected, and thus jumps 2 steps. Check from 0:39 into the video. This link should work https://youtu.be/vz39QwM1Acs?t=39

Created at 4 weeks ago
opened issue
OSC - No message exists for scene color

Software: Bitwig 4.3.4 DrivenByMoss-17.5.0-Bitwig Windows 10

Within Bitwig you can set a color per scene. However, no OSC message is documented or sent when setting/changing a scene color. Consider adding.

Created at 4 weeks ago
issue comment
OSC - When scrolling using bank/+ and bank/-, incorrect selected track indication when out of range

An additional note to highlight that the manual also indicates that the message should be sent. I will create a video showing the problem as soon as time permits: image

Created at 4 weeks ago
issue comment
OSC - When scrolling using bank/+ and bank/-, incorrect selected track indication when out of range

Not sure how to describe this better. Please check the screenshots agsin: the selected track is no longer on the track page, but there is no message received saying that that "track page" track 1 is no longer the selected track.

Track 1 on the track page remains indicated as selected, as no more selected updates are sent as soon as the selected track goes outside the track page.

Created at 4 weeks ago
issue comment
OSC - When scrolling using bank/+ and bank/-, incorrect selected track indication when out of range

Maybe a misunderstanding, I don't want to change track selection. The bug is that no message is sent when the selected track is no longer the first track on the current page. Please note that correct messages are sent to indicate that the "relative" track on the track page is (or not) the selected track, but this message is not provided when the selected track goes outside the track page.

Created at 4 weeks ago
issue comment
OSC - Incorrect panning setting in messages after '/pan/reset'

Thank you, didn't realize the takeover setting would apply to OSC messages as well. No way to avoid this? I'm also using other controllers.

Created at 4 weeks ago
issue comment
Empty OSC mapping in Bitwig

Thank you, understood.

Created at 4 weeks ago
opened issue
OSC - Incorrect panning setting in messages after '/pan/reset'

Software: Bitwig 4.3.4 DrivenByMoss-17.5.0-Bitwig Windows 10

After using '/pan/reset' and then sending a new panning value, it leads to a random panning value being set in Bitwig. Normally stuck at -100% (0) or 100% (127). Subsequent updates work correctly. Sending a FLOAT or INT32 does not make a difference.

There could be some different underlying issue, or there may be other functions affected in the same way, but this is what I've observed.

Message log from TouchOSC below:

23:58:59.156 | SEND       | ENDPOINT(192.168.0.101:8000) ADDRESS(/track/4/pan/reset)
23:58:59.177 | RECEIVE    | ENDPOINT([::ffff:192.168.0.101]:59620) ADDRESS(/update) INT32(1)
23:58:59.177 | RECEIVE    | ENDPOINT([::ffff:192.168.0.101]:59620) ADDRESS(/track/4/panStr) STRING(0.00 %)
23:58:59.177 | RECEIVE    | ENDPOINT([::ffff:192.168.0.101]:59620) ADDRESS(/track/4/pan) INT32(64)
23:58:59.177 | RECEIVE    | ENDPOINT([::ffff:192.168.0.101]:59620) ADDRESS(/update) INT32(0)
23:59:07.157 | SEND       | ENDPOINT(192.168.0.101:8000) ADDRESS(/track/4/pan) FLOAT(19.984459)
23:59:07.177 | RECEIVE    | ENDPOINT([::ffff:192.168.0.101]:59620) ADDRESS(/update) INT32(1)
23:59:07.177 | RECEIVE    | ENDPOINT([::ffff:192.168.0.101]:59620) ADDRESS(/track/4/panStr) STRING(-100 %)
23:59:07.177 | RECEIVE    | ENDPOINT([::ffff:192.168.0.101]:59620) ADDRESS(/track/4/pan) INT32(0)
23:59:07.177 | RECEIVE    | ENDPOINT([::ffff:192.168.0.101]:59620) ADDRESS(/update) INT32(0)
Created at 4 weeks ago
opened issue
OSC - When using

Software: Bitwig 4.3.4 DrivenByMoss-17.5.0-Bitwig Windows 10

When scrolling using OSC '/track/bank/+' and '/track/bank/-' and the selected track goes out of range (i.e. outside of the normally 8 tracks), there is no OSC message being sent indicating that a previously indicated "selected" track is no longer selected. In practice, this normally means that Track 1 or Track 8 remains indicated as Selected.

Note in the below log extract how there is no message indicating that /track/1 is no longer the selected track as it goes out of range (question mark in the image). A message like this would be expected where the question mark is: RECEIVE | ENDPOINT([::ffff:192.168.0.101]:63286) ADDRESS(/track/1/selected) INT32(0)

image

End-state as per image below. Note: as per OSC data, track 1 is never indicated as no longer selected, although the selected track "Audio 3" is no longer in the range: image

Created at 4 weeks ago
opened issue
Empty OSC mapping in Bitwig

Software: Bitwig 4.3.4 DrivenByMoss-17.5.0-Bitwig Windows 10

When pressing the "OSC" text in under Settings -> Controllers -> Any 'Open Sound Control' item, the web page is generated doesn't contain any information, only headers:

Button to click: image

Output: image

Created at 4 weeks ago
opened issue
OSC - incorrect isPlayingQueued and isStopQueued

Software: Bitwig 4.3.4 DrivenByMoss-17.5.0-Bitwig Windows 10

When launching a clip, the messages "isPlayingQueued" and "isStopQueued" are always sent out together and with the same value attached (1 or 0). This seems to be wrong, surely the "isPlayingQueued" message should only be sent when a clip is queued to be played, and vice versa for the "isStopQueued" message when a stop is queued.

When stopping a clip, no message is sent out at all ("isStopQueued" would be expected) until an "isPlaying 0" is sent out.

Extract from OSC log below:

22:50:00.043 | RECEIVE    | ENDPOINT([::ffff:192.168.0.101]:53217) ADDRESS(/update) INT32(1)
22:50:00.043 | RECEIVE    | ENDPOINT([::ffff:192.168.0.101]:53217) ADDRESS(/track/1/clip/1/isPlayingQueued) INT32(1)
22:50:00.043 | RECEIVE    | ENDPOINT([::ffff:192.168.0.101]:53217) ADDRESS(/track/1/clip/1/isStopQueued) INT32(1)
22:50:00.043 | RECEIVE    | ENDPOINT([::ffff:192.168.0.101]:53217) ADDRESS(/track/selected/clip/1/isPlayingQueued) INT32(1)
22:50:00.043 | RECEIVE    | ENDPOINT([::ffff:192.168.0.101]:53217) ADDRESS(/track/selected/clip/1/isStopQueued) INT32(1)
22:50:00.043 | RECEIVE    | ENDPOINT([::ffff:192.168.0.101]:53217) ADDRESS(/update) INT32(0)
22:50:00.071 | RECEIVE    | ENDPOINT([::ffff:192.168.0.101]:53217) ADDRESS(/update) INT32(1)
22:50:00.071 | RECEIVE    | ENDPOINT([::ffff:192.168.0.101]:53217) ADDRESS(/play) INT32(1)
22:50:00.071 | RECEIVE    | ENDPOINT([::ffff:192.168.0.101]:53217) ADDRESS(/time/str) STRING(0.00.00:000)
22:50:00.071 | RECEIVE    | ENDPOINT([::ffff:192.168.0.101]:53217) ADDRESS(/beat/str) STRING(1.1.1:00)
22:50:00.071 | RECEIVE    | ENDPOINT([::ffff:192.168.0.101]:53217) ADDRESS(/track/1/clip/1/isPlayingQueued) INT32(0)
22:50:00.071 | RECEIVE    | ENDPOINT([::ffff:192.168.0.101]:53217) ADDRESS(/track/1/clip/1/isStopQueued) INT32(0)
22:50:00.071 | RECEIVE    | ENDPOINT([::ffff:192.168.0.101]:53217) ADDRESS(/track/selected/clip/1/isPlayingQueued) INT32(0)
22:50:00.071 | RECEIVE    | ENDPOINT([::ffff:192.168.0.101]:53217) ADDRESS(/track/selected/clip/1/isStopQueued) INT32(0)
22:50:00.071 | RECEIVE    | ENDPOINT([::ffff:192.168.0.101]:53217) ADDRESS(/update) INT32(0)
22:50:00.092 | RECEIVE    | ENDPOINT([::ffff:192.168.0.101]:53217) ADDRESS(/update) INT32(1)
22:50:00.092 | RECEIVE    | ENDPOINT([::ffff:192.168.0.101]:53217) ADDRESS(/track/1/clip/1/isPlaying) INT32(1)
22:50:00.092 | RECEIVE    | ENDPOINT([::ffff:192.168.0.101]:53217) ADDRESS(/track/selected/clip/1/isPlaying) INT32(1)
22:50:00.092 | RECEIVE    | ENDPOINT([::ffff:192.168.0.101]:53217) ADDRESS(/update) INT32(0)

22:50:02.286 | RECEIVE    | ENDPOINT([::ffff:192.168.0.101]:53217) ADDRESS(/update) INT32(1)
22:50:02.286 | RECEIVE    | ENDPOINT([::ffff:192.168.0.101]:53217) ADDRESS(/time/str) STRING(0.00.02:171)
22:50:02.286 | RECEIVE    | ENDPOINT([::ffff:192.168.0.101]:53217) ADDRESS(/beat/str) STRING(1.4.4:92)
22:50:02.286 | RECEIVE    | ENDPOINT([::ffff:192.168.0.101]:53217) ADDRESS(/track/1/clip/1/isPlaying) INT32(0)
22:50:02.286 | RECEIVE    | ENDPOINT([::ffff:192.168.0.101]:53217) ADDRESS(/track/selected/clip/1/isPlaying) INT32(0)
22:50:02.286 | RECEIVE    | ENDPOINT([::ffff:192.168.0.101]:53217) ADDRESS(/update) INT32(0)
Created at 4 weeks ago
TommyC81 create tag 1.34
Created at 1 month ago

Amend vehicle removal process.

First look for empty vehicles, then all vehicles. Still removing the oldest vehicle as it goes.

Created at 1 month ago

Add X rule for emptying a line of vehicles

Adds a rule "X" that will ensure no more vehicles are added to a line, and all empty vehicles removed.

Created at 2 months ago
TommyC81 create tag 1.33
Created at 2 months ago
issue comment
Arturia Minilab Mk2 - Relative #1 vs #2 oddity

Ah, I see, good catch!

For sure, the virtual Multi controllers work well when assigning manually.

If time permits, I'll play with MidiView to see if any other settings on the MiniLab will make a difference.

On a separate note, I did run MidiView on my AKAI MPK Mini mk3; although the output is set as relative which for Akai should produce "1" for increment and "127" for decrement, it intermittently outputs 2 and 126 instead (seemingly 1-2% of the time). No obvious reason why.

Created at 2 months ago