I am attempting to install Cubase Elements 10.5 'stay at home trial but fail to get any audio.
I have followed numerous guides online about shuffling various Gb files around (surely thats the installer job) but still nothing.
All audio mapping shows as connected.
When testing eg using the Production > Blues Rock Production (so its not even setup), for each Channel I get the error message:
The current preset or project was created with a previous version of HALion Sonic SE. If you modify the preset using new features of this trial version a previous version might not be able to load it or the preset might sound different
if I just click ok and load the project it seems to play, but no audio or output levels show.
I am getting nowhere with Steinburg 'Support', raised a support request and this is just ignored.
I have been trying to get this working for about a month and installed several times.
VST Connections
Audio Device and Driver
The application is in focus when it fails to provide audio, not sure where to make it play in background.
Screenshots of fault:
Chose a project as test, but when loading each of the channels shows this error,
I click ok to make it load:
Press play, no sound
but see it playing here:
Attach a screenshot of your VST connections in Cubase to help others diagnose your system.
Ensure you have latest drivers for your audio card etc.
Ensure your operating system (or any other background/foreground app) is not using the outputs you have selected in Cubase.
as they may not be multi-client.
ASIO compatible hardware is recommended.
Ensure background audio is enabled in Cubase if the application is not in focus.
Confirm that you have followed at least the steps above in any further replies. Specify your level of experience with computer audio in general, so that further information is relevant to you :-)
Related
I have an application requirement where certain audio settings need to be made at the hardware level rather than the session level. I have been able to hit most of the areas in question using a third party API. However, a new requirement has come up and I'm having trouble accessing the setting.
We are primarily on Win7 systems though Win10 is not out of scope. We need to be able to disable Line-In as it appears to be causing some interference with the later run session recordings that are made.
Our working environment includes multiple systems/locations. The application that handles recordings is specialized and cannot be changed for something like a base setting. Also, with newer systems the line-in and rear microphone are a combined plug and, when used, the OS asks which way you want to use it.
I realize that changing audio settings and the hardware level can be problematic but any help or suggestions would be greatly appreciated as this project needs to completed as quickly as possible.
I acquired a batch of WT0490 wearable pdas with detachable scan head, so converted an application originally made for Windows Mobile (which has been running perfectly for several years) to run on the WT4090s. The devices use these versions:
Windows CE 5.0
EMDK 2.6
ASP.net CF 2.0
Since rollout I've seen some very frustrating behaviour, which seems to start happening after the devices have been operating a few days. Users are reporting the following error:
Unexpected error in application
SCAN_Enable
There doesnt seem to be any noticeable pattern, several devices will be working perfectly for a few days then suddenly this error will show. THen a few days and a few reboots later they work again.
All devices were taken right back to stock settings then our cabs deployed to them. All identical models. We've tried altering memory allocation, swapping scanner headers etc but there is no pattern.
The error seems to occur on load of the first form after login, the login screen displays a list of users in a dropdown with a password box so that part of the app works ok, it seems to be when the scanner is initialised that this failure happens.
I had 40 devices, now 30+ have gone down with this same issue so my gut is telling me its a software issue but as yet ive not been able to find out why.
We've tried warm boots, cold boots, complete reprovisionings as well. We have a couple of dev units that don't show the problem although they are not in regular use so maybe we just haven't seen the problem 'yet'.
I hope someone out there has had this issue and knows how to fix it.
Thanks in advance.
WT4090 was built by Motorola Solution enterprise business, now part of Zebra Technologies. The WT4090 is currently in EOS (End Of Sales) but is still supported by Zebra if you've a maintenance contract.
You can check if you've the latest OS version and fixes installed on the device looking on Zebra Technologies support website.
For question on how to develop for Zebra Technologies devices you can take a look at Launchpad, Zebra's developer community website.
It's Worth noting that these devices have detachable barcode scanners - so if the scanner is not correctly attached, you get a SCAN_Enable error.
If you don't release the scanner, you can also see this error as a previous form could have the scanner blocked.
You may also find you have the ScanWedge app running - this will also block the scanner so you cannot get it enabled. The EMDK needs exclusive access to the scanner to enable it.
My laptop's processor doesn't support SLAT so I can't run the WP8 emulator on my laptop and use that to take screenshots.
I have a Lumia 920 and I can take screenshots with it, but only for one of the three screen sizes available on Windows Phone.
Is there any way to take screenshots for all the different screen sizes in this case?
I had the same problem. There is not a way to have your Lumia 920 render in a different resolution if that's what you're asking. This makes verifying those resolutions pretty tough. It really makes you have to trust in your layout that your application can scale correctly.
To get the screenshots, I used my Lumia 920 to take screenshots, then I used paint.net to resize the images to the correct sizes for the store requirements. It's a little misleading to the user but it's all you can do without having the devices you need to test.
Other options would be to reach out to your local Microsoft developer evangelist to see if you can get a device to test those resolutions. Then if all else fails and you're still not comfortable shipping your app without testing on those resolutions you can always find a developer friend that is willing to run your app on their emulator.
If you're using a Windows Phone 8, you can just press the Power and Start buttons simultaneously to take a screenshot.
This is one of my coding projects. I'm fairly new to linux, so I need some pointers and thoughts from you guys, before I get started. I know there exists screen sharing software already, but I want to make my own! (=
Specifically, I want to clone my laptop screen to my TV over WLAN, via a linux box that is connected to a TV through a VGA cable:
Laptop streams it's screen
Linux box reads the stream
Linux box outputs the stream into the TV (through a VGA cable)
First of all, how do I record the screen and send the stream in real time in linux?
Secondly I must write a program that reads the stream being sent. The program must listen to some port, and collect the data being streamed from the laptop. Any thoughts?
Then I must output that data in real time to the TV. Do you how any ideas on how to solve this?
Thanks!
Edit: Regarding programming languages, I'm most comfortable with python.
Sharing your screen can be done via the various flavors of VNC (ie. RealVNC, TightVNC, UltraVNC, etc.). Most of them are Open Source, you might want to:
Stick with the VNC protocol for later compatibility
Take example of how the established solutions does for screen-hooking.
In Linux, the graphics are all processed by Xorg (new version of X Server), which was developed with networking embedded. This explains why you can ssh -X into a machine, execute a graphical interface on it and see it on your remote computer. I recommend you to read about hooks on Xorg to achieve your needs.
You need a client-server topology to achieve your needs. You are not talking about any programming language you forecast to use, though. Some languages may be harder than some to start with. Furthermore, this kind of code is already really well understood under every major programming language. You should try to at least use a framework that simplifies your networking portion of the project.
Sharing a screen on the TV can be done by your video card driver in Linux. Just check on your Desktop Environment (KDE and Gnome offers video configuration panels, for example) or in your video card configuration (nVidia and ATI Linux drivers offers multiple screen support)
It seems to me like you're trying to reinvent the wheel and are not too sure about how to begin. I recommend you to begin simple with one of the already proven VNC software and see how it goes from there. If a feature is missing, you've got the source code of the server and the client, so you can continue development of these projects. Once you've got your setup working, start thinking about replacing a single piece of the puzzle by your own code, and see how it goes.
Do not expect good (full HD, for instance) video quality on your TV without some very capable CPU/GPU and a 802.11n wireless network empty of users and be ready to accept some lag for the codecs to kick in.
You should try to take as small steps as possible. If I were taking up such a project, my first step would be to try to implement a solution using standard unix tools (e.g. netcat or socat for the network part, mplayer or vlc for the playback and maybe ffmpeg for the capture)? Then, replace each component with custom-written ones if needed.
I'm looking for a really really small linux distribution or process of making my own that's sole purpose is to get an air application to launch full screen and stay there; Essentially I'm building a home kitchen computer that runs entirely as an AIR app.
I have looked into using windows xp; and windows xp embedded but they pose so many issues I figured I'd try modern linux.
I have also seen TinyCore Linux which looks interestingly small but not sure what issues that poses in regards to running AIR and "hardware" accelerated display. I've also thought about stripping down an Ubuntu installation but I'm sure somebody must have done this already; google is just failing me right now...
I'm also interested in running an "embedded" version of say android and running the air app on some arm-based hardware again; with just the AIR runtimes only - although this is less preferred as it's more complex.
I'm also hooking this up to a touch screen monitor (not yet arrived) so I'll need to hunt down or write some drivers for translating the touch events into something AIR can understand... (this was my main intention for using windows in that all the drivers will just work).
What I'm after
Minified Linux kernel with JUST the drivers for the box I need
X Display with accelerated graphics support (Doesn't have to be X if AIR can run on a frame buffer?)
Running a Full screen AIR application (simple enough)
Ability to write back to the filesystem (enough support for AIR)
SSH Access for remote control
Samba for updating the filesystem (easier to maintain the system)
Touch screen support (3M Ex III I think...)
Audio support
Don't need
Don't need any window manager or any other GUI tools unless required by AIR
Don't need any toolbars or file managers or anything; The AIR app is the "OS"
Don't need any package managers or repos
Don't need multi user or logging in; everything can just run as an unprivileged account
Don't need to
I don't mind hand crafting the filesystem and configs if that makes it easier; I'm mainly looking for a "filesystem" that is as tiny as possible that I can just plop my AIR app into and write some scripts to get it to start when the X server starts
Thanks,
Chris
Try an embedded Linux build system such as Buildroot. It can build an entire system from source, and be very lightweight. The basic system is less than 1 MB in size.
Ended up going with Tiny Core. Very tiny and quick to boot up. You can also write extensions for it and you don't have a persistent drive which allows you to just switch the thing off without worry that it's going to break something -- exactly what you need in a kitchen :-D.
My current plan is to:
Just set up a working version using Ubuntu as this is mostly supported by Adobe
Slowly strip it back and try and get as little things to start as possible on boot
Try building my own distro/package from source and selecting only the packages I need
Compile my own kernel with nearly everything turned off and just leave on the things I need