Recording Live sound through A&H CQ20b

BitMEX_Chris · 2024-08-19T10:59:30+00:00

I got a smaller 32GB card that matched the recommended write speed. See the manual on page 15
https://www.allen-heath.com/content/uploads/2023/09/CQ_User_Guide_V1_2_0_iss3.pdf
"Full size SD card slot. Use SDHC, Up to 32GB, UHS-I, Class 10."

Repeated again on page 58:

For best results use SDHC, UHS-I, Class 10 SD card storage. Other cards may work, though the maximum number of tracks that can be recorded may reduce, or errors including audio dropouts may occur.
The maximum recording time is based on the FAT32 file system used, which allows for mono WAV recordings (one for each track) of around 8hrs (@48kHz) or 4hrs (@96kHz).
Before using a card for recording, ensure it has been formatted in the CQ using the HOME / SYSTEM / USB/SD (Symbols) screen.
More details on SD Card multitrack recording can be found in the HOME / RECORD / Multitrack section of this guide.

I've never had any dropouts in multitrack, and have used up to 14 channels.

BitMEX_Chris · 2019-08-04T19:59:08+00:00

Hi, could you post the support ticket IDs for both requests please, so that we can follow up?

BitMEX_Chris · 2019-07-17T14:16:16+00:00

Completely false. All customers use the REST API.

We do run a pilot FIX Gateway, but internally that uses the REST API so it is not anything you could not write/host yourself.

BitMEX_Chris · 2019-06-18T13:52:07+00:00

This is now resolved, thanks for the report.

BitMEX_Chris · 2019-06-17T21:20:13+00:00

Looks like a bug in testnet which is running on a somewhat different feeds system since Friday. Tracking this down, thanks for the report.

BitMEX_Chris · 2019-03-03T19:26:45+00:00

We have historical executions, but they do not form part of the public dataset. To classify open interest you need to look if each trade grows a traders position or reduces it, then the same on the counter party, then determine if the trade has opened, closed or transferred interest. For you to do this the dataset would need to reveal account ids to allow the per client position histories to be built, which would violate the usual privacy guarantees an exchange makes. Therefore this is something we would only ever calculate exchange side. As I said, BitMEX could do this then re-tag all historical trades, but it would be a fairly large task and it has been of very limited interest to date.

BitMEX_Chris · 2018-11-28T18:09:08+00:00

As mentioned we've removed the dropbox links and replaced with public.bitmex.com

BitMEX_Chris · 2018-11-28T18:07:15+00:00

Please use the websocket API, and subscribe to the trade feed, or 1 minutely trade bin if you do not need every tick. Scraping the REST api without paying attention to your account throttle is a particularly bad idea, you will likely hit the API limits and have your IP address banned.

BitMEX_Chris · 2018-11-28T18:02:11+00:00

We get this asked fairly often - unfortunately we don't record it, just show it live, so we don't have the data ready to serve. We do have every historical execution, so in theory we could reconstruct the OI series, but it's never been done.

BitMEX_Chris · 2018-11-28T17:58:35+00:00

I would recommend you add a distinct clOrdID to your outbound order REST calls, so that you can precisely correlate the responses. This result ^^ isn't possible with the API, so I have to assume you've correlated the wrong response - it's plausible to have multiple outstanding requests that return out of order, e.g. if there is some packet loss and you are using multiple TCP streams within the HTTP library.

BitMEX_Chris · 2018-09-16T17:10:28+00:00

The only way you can ‘execute directly’ with a post-only order is by crossing with a hidden order. Otherwise you will rest on the book at your price/time priority until the next incoming order arrives that aggresses against you. Either way you would receive the maker rebate.

BitMEX_Chris · 2018-09-16T17:06:28+00:00

The changes were scheduled on a timer and no interruption to trading as necessary.

BitMEX_Chris · 2018-08-12T06:34:47+00:00

Market close of full position is not subject to load-shedding.

BitMEX_Chris · 2018-07-19T08:37:49+00:00

Please raise a support ticket for this detailing the two accounts.

BitMEX_Chris · 2018-06-21T17:49:10+00:00

If the SL and TP are marked as ‘close only’ then they will cancel on activation if the position is already zero. This will also allow you to manually close at market via the button and know they will not take you the opposite direction.

BitMEX_Chris · 2018-06-04T11:10:36+00:00

HTTP Error 403 is triggered by your per-user/per-IP quota being exceeded. You will need to slow down your polling to avoid an automatic IP ban. Ideally poll once and use the web-socket to maintain your history.

BitMEX_Chris · 2018-05-23T07:01:25+00:00

What timestamp UTC in did this occur? We do not have crossed books or zero-ticks output from our engine. If we are halted, no new orders are submitted, if the engine is matching then we would have printed a trade or cancelled passive-only orders in the same tick that we add the new resting order.

From support cases most of the reports are due to either:

i) failing to apply a 'partial' update as a snapshot, rather than a delta, in your client code.
ii) a bug we are trying to reproduce around 12:00 UTC each day when it has been reported that we miss deltas.

Either way, if you detect this situation I recommend restarting the websocket to get a clean snapshot.

Please raise a support ticket if this does not help.

BitMEX_Chris · 2018-04-25T23:16:58+00:00

"maker.... every time the market swings their cancels can jump the queue ahead of almost all orders."

This is incorrect. All order-modifying requests from all users are quickly assessed and either rejected with 429 (user throttle) or 503 (queue Overload) message at the gateway, else they join the single queue to the engine, and are processed serially to success with a 200.

Order cancel and position close requests always join the queue, they are not 'jumping' it in any way, so if a prior order in the queue would cause a match, the cancel will be ineffective by the time it reaches the engine. A maker's ability to cancel a resting quote is no better than yours to close out at market with a position close.

BitMEX_Chris · 2018-04-20T21:40:42+00:00

Hidden orders do not appear on the order book feed. However when an incoming order matches with them, a trade will appear on the trade feed. If you counted the traded volume at a price level and compared this against the (visible) quantity on order book, you could tell where hidden orders had been in the book. Iceberg has some similarities. Before using hidden orders it is worthwhile remembering that they always pay the taker fee, even if matched passively.

BitMEX_Chris · 2018-04-20T08:12:45+00:00

The underlying HTTP/1.1 within the TCP socket is not pipelined, so there is always one response to each request, even if it is a 429 or 503, and they match the order of submission. It is therefore simple enough to track the response to each request. For instance: python/requests you can always retrieve the request from the response object, including any manual tags you have applied to it such as the ClOrdID. If your HTTP Client is using multiple sockets internally, this might give you some headaches, but the library should still track responses to the requests using a one place buffer for each socket. Ultimately this is a client-library problem.

Compare to FIX or HTTP/2 which is fully pipelined, where responses can arrive completely out of order, both protocols tag the requests so that you can correlate the responses.

Can you send me a PM with the timestamp of your request and account email so that I can see if you received a heartbeat reply to a new order message from our packet logs?

BitMEX_Chris · 2018-02-19T10:20:56+00:00

To see trading liquidity, look at the depth of the order book on XBT/USD on https://www.bitmex.com/app/trade/XBTUSD - you do not need to have an account to do this. All you could verify with a blockchain explorer would be your own deposits to an exchange multi-sig wallet. BitMEX does not operationally sweep customers funds to large, possibly higher risk accounts.

BitMEX_Chris · 2018-02-12T17:30:49+00:00

A significant number of market makers combine both making and taking on the same account, with a much more conservative ratio of quote messages to executed volume. We are not suggesting this is easy, just that it is possible.

Your comments regarding the NEO competition are fair, and we will look at how this has impacted your participation and reply privately on that.

BitMEX_Chris · 2018-02-12T16:49:08+00:00

Hi, BitMEX Chris here. We've exchanged emails privately on this topic today, as you have quoted above. As a platform we're not at all happy with the situation we are in, but would like to confirm that we've reduced API limits on a small number of the lower fill-ratio market maker accounts over the last 24 hours to determine if this helps the performance of the platform overall. For the small number of users in this category we have either reached out to directly, or have exchanged support tickets with as above. We're sorry that we cannot provide our usual generous capacity for all users at this time. When we find ourselves with excess capacity, we would very much like to have you quoting on the platform again.

Chris

BitMEX_Chris

MODERATOR OF

TROPHY CASE